DO NOT REPLY [Bug 5349] New: - A nonfatal internal JIT (3.00.078(x)) error 'Relocation error

[bugzilla]

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

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

A nonfatal internal JIT (3.00.078(x)) error 'Relocation error

   Summary: A nonfatal internal JIT (3.00.078(x)) error 'Relocation
error
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when I try to start tomcat3.3 server on Win NT following error is displaying 
in  my m/c.
A nonfatal internal JIT (3.00.078(x)) error 'Relocation error: NULL relocation 
t arget' has occurred in : 'org/apache/crimson/parser/Parser2.maybeComment (Z)
Z': Interpreting method. Please report this error in detail to 
http://java.sun.com/cgi-bin/bugreport.cgi

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

Re: AJP Todo

[Bill Barker]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 10, 2001 8:59 PM
Subject: Re: AJP Todo


>
>
> On Mon, 10 Dec 2001, Bill Barker wrote:
>
> > Date: Mon, 10 Dec 2001 20:00:35 -0800
> > From: Bill Barker <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: AJP Todo
> >
> >
> > - Original Message -
> > From: "Incze Lajos" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> > Sent: Monday, December 10, 2001 8:02 AM
> > Subject: Re: AJP Todo
> >
> >
> > > What's wrong with this? (ServletContext method javadoc both 2.2 and
2.3)
> >
> > Absolutely nothing.  And indeed this is the route I took, since looking
at
> > the code showed that the Naming methods still didn't guarantee an
absolute
> > path and this one always returns null for non-file-based contexts.
> >
>
> That's because there *is* no such thing as an absolute path for an entry
> inside a WAR file.  Talk to your favorite OS vendor about that one.

Don't get so touchy :).  I'm certainly not going to criticize Tomcat 4.x
when I'm the first to admit that I don't know it very well.  I was actually
referring to FileDirContext.getNameInNamespace when I was talking about
non-absolute paths.  As it is now, ${Server}Config does a forwardAll if the
Context is defined by a WAR file.

>
> > Now if I can just find someone to Listen to, I'll be done :).
>
> What is it you think should be changed?

I don't know about "changed".  I'll simply describe the problem I'm facing.
A lot of users simply want to include one ApacheConfig statement in the
server.xml, include that file in the httpd.conf file and forget about it.
In order to get the configuration info, I need to Listen to somebody who
fires the START_EVENT at the end of Lifecycle.start (e.g. Container and
derived).  This leaves Host as the highest level I can Listen to.  However,
there are some one-time-only entries in the file that can't be repeated, so
Host doesn't work so well for simple configurations.  I'd really like Server
(since it is a singleton), but Server fires it's event at the beginning, so
the sub-elements aren't configured yet.  At the moment, I'm thinking that if
I'm Listening to a Server, I'll write the one-time-only information.  Then
you'll have to Listen to any Host or Context that you want configured as
well.
>
> Craig
>
>
> > > 
> > > getRealPath
> > >
> > > public java.lang.String getRealPath(java.lang.String path)
> > >
> > > Returns a String containing the real path for a given virtual path.
> > > For example, the path "/index.html" returns the absolute file path
> > > on the server's filesystem would be served by a request for
> > > "http://host/contextPath/index.html";, where contextPath is the context
> > > path of this ServletContext..
> > >
> > > The real path returned will be in a form appropriate to the computer
and
> > > operating system on which the servlet container is running, including
the
> > > proper path separators. This method returns null if the servlet
container
> > > cannot translate the virtual path to a real path for any reason (such
as
> > > when the content is being made available from a .war archive).
> > > -
> > > So, getServletContext().getRealPath( "/" )
> > >
> > > incze
> > >
> > > --
> > > To unsubscribe, e-mail:
> > 
> > > For additional commands, e-mail:
> > 
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:

> > For additional commands, e-mail:

> >
> >
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: AJP Todo

[Craig R. McClanahan]

On Mon, 10 Dec 2001, Bill Barker wrote:

> Date: Mon, 10 Dec 2001 20:00:35 -0800
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: AJP Todo
>
>
> - Original Message -
> From: "Incze Lajos" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, December 10, 2001 8:02 AM
> Subject: Re: AJP Todo
>
>
> > What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)
>
> Absolutely nothing.  And indeed this is the route I took, since looking at
> the code showed that the Naming methods still didn't guarantee an absolute
> path and this one always returns null for non-file-based contexts.
>

That's because there *is* no such thing as an absolute path for an entry
inside a WAR file.  Talk to your favorite OS vendor about that one.

> Now if I can just find someone to Listen to, I'll be done :).

What is it you think should be changed?

Craig


> > 
> > getRealPath
> >
> > public java.lang.String getRealPath(java.lang.String path)
> >
> > Returns a String containing the real path for a given virtual path.
> > For example, the path "/index.html" returns the absolute file path
> > on the server's filesystem would be served by a request for
> > "http://host/contextPath/index.html";, where contextPath is the context
> > path of this ServletContext..
> >
> > The real path returned will be in a form appropriate to the computer and
> > operating system on which the servlet container is running, including the
> > proper path separators. This method returns null if the servlet container
> > cannot translate the virtual path to a real path for any reason (such as
> > when the content is being made available from a .war archive).
> > -
> > So, getServletContext().getRealPath( "/" )
> >
> > incze
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: AJP Todo

[Bill Barker]

- Original Message -
From: "Incze Lajos" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 10, 2001 8:02 AM
Subject: Re: AJP Todo


> What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)

Absolutely nothing.  And indeed this is the route I took, since looking at
the code showed that the Naming methods still didn't guarantee an absolute
path and this one always returns null for non-file-based contexts.

Now if I can just find someone to Listen to, I'll be done :).
> 
> getRealPath
>
> public java.lang.String getRealPath(java.lang.String path)
>
> Returns a String containing the real path for a given virtual path.
> For example, the path "/index.html" returns the absolute file path
> on the server's filesystem would be served by a request for
> "http://host/contextPath/index.html";, where contextPath is the context
> path of this ServletContext..
>
> The real path returned will be in a form appropriate to the computer and
> operating system on which the servlet container is running, including the
> proper path separators. This method returns null if the servlet container
> cannot translate the virtual path to a real path for any reason (such as
> when the content is being made available from a .war archive).
> -
> So, getServletContext().getRealPath( "/" )
>
> incze
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java BaseJkConfig.java IISConfig.java NSConfig.java

[billbarker]

billbarker01/12/10 19:52:35

  Modified:jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java
BaseJkConfig.java IISConfig.java NSConfig.java
  Log:
  Fix the Alias mapping in "static by Apache" mode.
  
  Now the Alias directives are handled correctly, even for a Context that is declaired 
in the server.xml file.  Also, a Context that is based in an un-expanded WAR file gets 
a forwardAll in all configurations.
  
  Based on suggestion from Incze Lajos [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.2   +14 -18
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/ApacheConfig.java
  
  Index: ApacheConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/ApacheConfig.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ApacheConfig.java 2001/12/10 03:52:02 1.1
  +++ ApacheConfig.java 2001/12/11 03:52:35 1.2
  @@ -274,21 +274,6 @@
return new PrintWriter(new FileWriter(abJkConfig, append));
   }
   
  -/**
  -executes the ApacheConfig interceptor. This method generates apache
  -configuration files for use with  mod_jk.
  -
  -@param context a Context object.
  -*/
  -public void executeContext(Context context, PrintWriter mod_jk){
  -
  - if(context.getPath().length() > 0 || ! noRoot ) {
  - if( forwardAll )
  - generateStupidMappings( context, mod_jk );
  - else
  - generateContextMappings( context, mod_jk);
  - }
  -}
   
   //  Config sections  
   
  @@ -397,7 +382,7 @@
   /** Forward all requests for a context to tomcat.
The default.
*/
  -private void generateStupidMappings(Context context,
  +protected void generateStupidMappings(Context context,
   PrintWriter mod_jk )
   {
String ctxPath  = context.getPath();
  @@ -436,7 +421,7 @@
   //  Apache serves static mode 
   // This is not going to work for all apps. We fall back to stupid mode.
   
  -private void generateContextMappings(Context context, PrintWriter mod_jk )
  +protected void generateContextMappings(Context context, PrintWriter mod_jk )
   {
String ctxPath  = context.getPath();
Host vhost = getHost(context);
  @@ -463,7 +448,7 @@
   
String [] servletMaps = context.findServletMappings();
for(int ii=0; ii < servletMaps.length; ii++) {
  -   addMapping( ctxPath+ servletMaps[ii] , mod_jk );
  +   addMapping( ctxPath, servletMaps[ii] , mod_jk );
}
   }
   
  @@ -486,6 +471,17 @@
   if( debug > 0 )
   log( "Adding map for " + fullPath );
mod_jk.println(indent + "JkMount " + fullPath + "  " + jkWorker );
  + return true;
  +}
  +/** Add a partially specified Appache mapping.
  + */
  +protected boolean addMapping( String ctxP, String ext, PrintWriter mod_jk ) {
  +if( debug > 0 )
  +log( "Adding map for " + ext );
  + if(! ext.startsWith("/") )
  + ext = "/" + ext;
  + if(ext.length() > 1)
  + mod_jk.println(indent + "JkMount " + ctxP + ext+ "  " + jkWorker );
return true;
   }
   
  
  
  
  1.2   +23 -6 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/BaseJkConfig.java
  
  Index: BaseJkConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/config/BaseJkConfig.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- BaseJkConfig.java 2001/12/10 03:52:02 1.1
  +++ BaseJkConfig.java 2001/12/11 03:52:35 1.2
  @@ -120,7 +120,7 @@
   @author Costin Manolache
   @author Larry Isaacs
   @author Bill Barker
  - @version $Revision: 1.1 $
  + @version $Revision: 1.2 $
*/
   public class BaseJkConfig  implements LifecycleListener {
   protected int debug=0;
  @@ -247,10 +247,26 @@
}
generateVhostTail(hst, mod_jk);
   }
  -/** Generate configuration files.  Override with method to generate
  -web server specific configuration.
  - */
  -protected void executeContext(Context ctx, PrintWriter mod_jk) {
  +/**
  +executes the ApacheConfig interceptor. This method generates apache
  +configuration files for use with  mod_jk.
  +
  +@param context a Context object.
  + @param mod_jk Writer for output.
  +*/
  +public void executeContext(Context context, PrintWriter mod_jk){
  +
  + if(context.getPath().length() > 0 || ! noRoot ) {
  + String docRoot = context.getServletContext().g

cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester Session04.java SessionListener01.java

[craigmcc]

craigmcc01/12/10 19:51:34

  Modified:tester/src/tester/org/apache/tester Session04.java
SessionListener01.java
  Log:
  Enhance logging of session creation and destroy events, to ensure that the
  right events are called when you invalidate an old session, and create a
  new one, within the same servlet request.  No functional change.
  
  Revision  ChangesPath
  1.2   +4 -1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Session04.java
  
  Index: Session04.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Session04.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Session04.java2001/04/11 04:31:08 1.1
  +++ Session04.java2001/12/11 03:51:34 1.2
  @@ -69,7 +69,7 @@
* identifier) while processing this request.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/04/11 04:31:08 $
  + * @version $Revision: 1.2 $ $Date: 2001/12/11 03:51:34 $
*/
   
   public class Session04 extends HttpServlet {
  @@ -77,6 +77,8 @@
   public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws IOException, ServletException {
   
  +log("Session04 - Starting, requestedSessionId = " +
  +request.getRequestedSessionId());
   response.setContentType("text/plain");
   PrintWriter writer = response.getWriter();
   
  @@ -184,6 +186,7 @@
   writer.println(message);
   }
   StaticLogger.reset();
  +log("Session04 - Stopping");
   
   }
   
  
  
  
  1.2   +9 -2  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SessionListener01.java
  
  Index: SessionListener01.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SessionListener01.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SessionListener01.java2001/04/18 19:53:09 1.1
  +++ SessionListener01.java2001/12/11 03:51:34 1.2
  @@ -64,10 +64,11 @@
   
   /**
* Application event listener for session events.  All events that occur
  - * are logged appropriately to the static logger.
  + * are logged appropriately to the static logger.  In addition, session
  + * creation and destruction events are logged to the servlet context log.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/04/18 19:53:09 $
  + * @version $Revision: 1.2 $ $Date: 2001/12/11 03:51:34 $
*/
   
   public class SessionListener01
  @@ -91,10 +92,16 @@
   
   public void sessionCreated(HttpSessionEvent event) {
   StaticLogger.write("SessionListener01: sessionCreated()");
  +HttpSession session = event.getSession();
  +session.getServletContext().log("SessionListener01: sessionCreated(" +
  +session.getId() + ")");
   }
   
   public void sessionDestroyed(HttpSessionEvent event) {
   StaticLogger.write("SessionListener01: sessionDestroyed()");
  +HttpSession session = event.getSession();
  +session.getServletContext().log("SessionListener01: sessionDestroyed("
  ++ session.getId() + ")");
   }
   
   
  
  
  

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

DO NOT REPLY [Bug 4542] - jsp:include inside a custom tag can throw an exception.

[bugzilla]

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

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

jsp:include inside a custom tag can throw an exception.





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 18:32 ---
The servlet error page specified in the deployment descriptor is a global error
handler, whereas the error page specified in a jsp page directive is error
handler local to the page.  Therefore the servlet spec does not apply to a JSP
page, which has it own rules governing errors.  Section JSP 2.4.2 states,

"Any uncaught exceptions thrown in the body of the JSP page implementation class
result in the fowarding of the client request and uncaught exception to the
errorPage URL specified by the JSP page (or the implementation default behavior,
if none is specified)."

It clearly indicates that errors occur in a page should be handled by its
errorPage, if specified.  In fact, the error page specified in the servlet
deployment descriptor need not be used, even if an errorPage is not specified in
a JSP page, since the "implementation default behavior" may choose to just
report the error without setting the error code in the response.

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

Bug 5329 question regarding fixing of the issue

[Andrew]

Is there any work on fixing the "inconsistent behavior" of the Warp connector 
for win32, or will the Warp connector be phased out in favor of the ajp 
connector?


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

DO NOT REPLY [Bug 5329] - NT Service exits startup before Tomcat is finished starting up.

[bugzilla]

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

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

NT Service exits startup before Tomcat is finished starting up.

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Unknown |Other Connectors



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 18:26 ---
Although more flexible connection handling in Apache might be desireable for 
some purposes, I do not believe that modifing the native code in Apache to only 
connect on demand would be a desireable solution to the problem. You would 
still run into problems for the short time that the connector is not yet ready 
to accept connections, and would also cause clients to recieve a 500 or 404 
errors until the connector is ready to accept connections.

Changing the code in Apache (and other native webservers) to accomodate an 
issue caused by an "inconsistency" in the Tomcat connectors would be 
undesireable if Tomcat is to remain independent of other software. I firmly 
believe that a piece of software (especially services on a server) should 
only "claim" to be ready if it is completly ready for all clients to access the 
service.

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

DO NOT REPLY [Bug 4843] - The stream from PageData.getInputStream() doesn't contain an encoding information

[bugzilla]

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

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

The stream from PageData.getInputStream() doesn't contain an encoding information

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 17:14 ---
This looks like the same problem as reported in 5096, which was fixed.  Please
try your test case with a current nightly build, and reopen the bug with a test
case if the bug is till present.  Make sure that utf-8 encoding is used.

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

HP-CSF and Tomcat

[LOYD,AARON (HP-FtCollins,ex1)]

Has anyone gotten Tomcat to run under HP's Core Services Framework?

Using Tomcat 3.2 I tried setting up a CSF service to start and stop Tomcat
using the Tomcat class and it's method execute().  Only to discover that
they are protected and can't be accessed outside the package.  Is there
another tie in point for starting and stopping Tomcat?

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

Re: [Fwd: using SSL_SESSION_ID for session tracking, anyone done it?]

[Eric Rescorla]

Joel Roth-Nater <[EMAIL PROTECTED]> writes:
> My idea is to let Apache handle SSL traffic, but pass the SSL_SESSION_ID 
> through mod_webapp to Tomcat. Tomcat could then use it to track its 
> sessions without cookies or URL-rewriting. Before I start writing the 
> code myself, I wonder if anyone has tried to do it.
If you're going to do this you're going to have to be prepared for
the case where a client reconnects but doesn't resume a previous
session. There's no guarantee in SSL that merely because a C/S 
pair have communicated previously (Even recently) that they will
resume that previous session. Clients and servers can flush the 
session cache at any time.

Session IDs aren't really a complete substitute for cookies.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
Author of "SSL and TLS: Designing and Building Secure Systems"
  http://www.rtfm.com/
  

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

Re: [Fwd: using SSL_SESSION_ID for session tracking, anyone done it?]

[Bojan Smojver]

Joel Roth-Nater wrote:
> 
> My idea is to let Apache handle SSL traffic, but pass the SSL_SESSION_ID
> through mod_webapp to Tomcat. Tomcat could then use it to track its
> sessions without cookies or URL-rewriting. Before I start writing the
> code myself, I wonder if anyone has tried to do it.
> 
> I've been all over the list-archives, source code and doc to no avail,
> yet the J2EE spec mandates "SSL" as one of the methods for session
> tracking. Am I missing something?

Don't know about TC 4.x, but 3.3 from CVS has support for checking
Tomcat session ID's against SSL session ID's to prevent session
hijacking. Not sure if that helps you in any way...

Bojan

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

DO NOT REPLY [Bug 5319] - AccessLogValve does not resolve hostname

[bugzilla]

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

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

AccessLogValve does not resolve hostname





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 12:42 ---
After looking through the source code and finding out that request.getRemoteHost
() also does not return the hostname, I found bug 4180 which may be the same 
problem. 

But as I'm not that familiar with the source, I would rather let an expert 
determine that :)

Charlie

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

Re: Connection reset by peer

[Renato]

It looks that this error however is happening at the connector pool level. 
I see other 'connection reset by peer' errors but they have different 
stacks. This one looks more critical. It might also a bug in the JVM.


> Hello,
> 
> I had the same problem with tomcat in windows environment. Its just that
> when ever your connection between Tomcat and its client (mostly a web
> browser) breaks (may be due to pressing stop button in the browser or due 
to
> any other reason) it throws exception. And the exception stack trace was
> printed on the console. So nothing to worry about this.
> 
> I am not too sure, but I guess your tomcat didn't hang due to this reason.
> There must be some other problem with your environment as well.
> 
> Regards,
> Ali.
> - Original Message -
> From: "Renato" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, December 10, 2001 5:26 PM
> Subject: Connection reset by peer
> 
> 
> > Hi all,
> >
> > I was looking through tomcat's log ( tomcat 3.2.4 + mod_jk under Red Hat
> > 7.2 + Sun JVM 1.3.1_01 ) and I saw a lot of messages like this:
> >
> > java.net.SocketException: Connection reset by peer: Connection reset by
> peer
> > at java.net.SocketInputStream.socketRead(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:86)
> > at org.apache.tomcat.service.connector.TcpConnector.receiveFully
> > (TcpConnector.java:150)
> > at org.apache.tomcat.service.connector.TcpConnector.receive
> > (TcpConnector.java:121)
> > at
> >
> 
org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection
> > (Ajp13ConnectionHandler.ja
> > va:146)
> > at org.apache.tomcat.service.TcpWorkerThread.runIt
> > (PoolTcpEndpoint.java:416)
> > at org.apache.tomcat.util.ThreadPool$ControlRunnable.run
> > (ThreadPool.java:501)
> > at java.lang.Thread.run(Thread.java:484)
> >
> > After a while Tomcat starts failing to respond till it hangs completely.
> >
> > I've seen Sun's JVM release and already set up the 'work around'
> parameters
> > for Linux.
> >
> > Any other hint ?
> >
> > Thanks
> > Renato.
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 
> 

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

tomcat 4 and response buffer size

[Kevin Seguin]

i just happened to notice that the behaviour of tomcat 4 response buffers
might not be as expected with respect to buffer size.  below is some code
from org/apache/catalina/connector/ResponseBase.java:

--- snip ---
public void write(byte b[], int off, int len) throws IOException {

if (suspended)
throw new IOException
(sm.getString("responseBase.write.suspended"));

// If the whole thing fits in the buffer, just put it there
if (len == 0)
return;
if (len <= (buffer.length - bufferCount)) {
System.arraycopy(b, off, buffer, bufferCount, len);
bufferCount += len;
contentCount += len;
return;
}

// Flush the buffer and start writing full-buffer-size chunks
flushBuffer();
int iterations = len / buffer.length;
int leftoverStart = iterations * buffer.length;
int leftoverLen = len - leftoverStart;
for (int i = 0; i < iterations; i++)
write(b, off + (i * buffer.length), buffer.length);

// Write the remainder (guaranteed to fit in the buffer)
if (leftoverLen > 0)
write(b, off + leftoverStart, leftoverLen);

--- end snip ---

it looks like when you are writing to a response, and the size of the new
chunk of data + the size of the existing data in the buffer is greater than
the buffer size, the existing data will be written to the client, then the
new data will be added to the buffer and all or part of it possibly written
to the client.

it may not make much of a difference, but i would have expected the internal
buffer to be completely filled before data is sent to the client.

for example, suppose your buffer size is 8K.  if you write 1 byte to the
response, then write 8K to the response, first 1 byte will be written to the
client, then 8K will be written to the client.  i would have expected this
to be the other way around.

probably not a big deal, just thought i'd point it out :)

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

DO NOT REPLY [Bug 5345] - Redirection fails in embedded Tomcat in wspack1-b06

[bugzilla]

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

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

Redirection fails in embedded Tomcat in wspack1-b06





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 12:14 ---
Catalina now enforces the spec requrements that the response is closed after a 
redirect or a sendError. So that's why it now fails.

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

DO NOT REPLY [Bug 5345] New: - Redirection fails in embedded Tomcat in wspack1-b06

[bugzilla]

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

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

Redirection fails in embedded Tomcat in wspack1-b06

   Summary: Redirection fails in embedded Tomcat in wspack1-b06
   Product: Tomcat 4
   Version: Nightly Build
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The redirection to another JSp fails in the embedded tomcat in the WSPack 1.0 
EA1 -b06

this is the JSP which redirects:
Name: Original.jsp

<%-- test JSP by Prasad --%>

<% String  path="Redirected.jsp"; %>
<% response.sendRedirect(path); %>

Pls get redirected !!

**
This is the JSP to which the redirection happens:
Name: Redirected.jsp


<%-- test JSP by Prasad --%>

This is the new JSP
**

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

Re: Connection reset by peer

[Muhammad Ali Siddiqui]

Hello,

I had the same problem with tomcat in windows environment. Its just that
when ever your connection between Tomcat and its client (mostly a web
browser) breaks (may be due to pressing stop button in the browser or due to
any other reason) it throws exception. And the exception stack trace was
printed on the console. So nothing to worry about this.

I am not too sure, but I guess your tomcat didn't hang due to this reason.
There must be some other problem with your environment as well.

Regards,
Ali.
- Original Message -
From: "Renato" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 10, 2001 5:26 PM
Subject: Connection reset by peer


> Hi all,
>
> I was looking through tomcat's log ( tomcat 3.2.4 + mod_jk under Red Hat
> 7.2 + Sun JVM 1.3.1_01 ) and I saw a lot of messages like this:
>
> java.net.SocketException: Connection reset by peer: Connection reset by
peer
> at java.net.SocketInputStream.socketRead(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:86)
> at org.apache.tomcat.service.connector.TcpConnector.receiveFully
> (TcpConnector.java:150)
> at org.apache.tomcat.service.connector.TcpConnector.receive
> (TcpConnector.java:121)
> at
>
org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection
> (Ajp13ConnectionHandler.ja
> va:146)
> at org.apache.tomcat.service.TcpWorkerThread.runIt
> (PoolTcpEndpoint.java:416)
> at org.apache.tomcat.util.ThreadPool$ControlRunnable.run
> (ThreadPool.java:501)
> at java.lang.Thread.run(Thread.java:484)
>
> After a while Tomcat starts failing to respond till it hangs completely.
>
> I've seen Sun's JVM release and already set up the 'work around'
parameters
> for Linux.
>
> Any other hint ?
>
> Thanks
> Renato.
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:



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

Re: [j-t-c] ajp and headaches

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, December 09, 2001 9:56 PM
Subject: Re: [j-t-c] ajp and headaches


> The tomcat4.0 adapter - yes. The connector code ( low level Request, etc )
> are based on MessageBytes, etc. It needs some tunning, but I
> wouldn't change it without some good reasons.
>
> I'm more interested in the low level stuff, and if possible I would like
> to keep a similar object model on both sides ( it'll help on JNI and in
> general ).
>
> The higher level needs some work...
>
> Kevin - if you have time, extracting the mapping out of tomcat4 would help
> a lot ! Also, for passing the 'route' to the session manager we need a bit

The extracting mapping logic is working fine in o.a.a.tomcat4.config.  You
can look there for a start.  What still needs work there is generating the
Alias directives (thanks Remy).  Of course, this method will be a big
improvement on the Listeners once it is in place.

> of code - we need to first "find" the session manager, then a small piece
> of code to set the jvmRoute on the request. I know this is not
> 'refactoring', but problems we need to solve asap.
>
> Costin
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

[Fwd: using SSL_SESSION_ID for session tracking, anyone done it?]

[Joel Roth-Nater]

My idea is to let Apache handle SSL traffic, but pass the SSL_SESSION_ID 
through mod_webapp to Tomcat. Tomcat could then use it to track its 
sessions without cookies or URL-rewriting. Before I start writing the 
code myself, I wonder if anyone has tried to do it.

I've been all over the list-archives, source code and doc to no avail, 
yet the J2EE spec mandates "SSL" as one of the methods for session 
tracking. Am I missing something?


-- Joel


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

Connection reset by peer

[Renato]

Hi all,

I was looking through tomcat's log ( tomcat 3.2.4 + mod_jk under Red Hat 
7.2 + Sun JVM 1.3.1_01 ) and I saw a lot of messages like this:

java.net.SocketException: Connection reset by peer: Connection reset by peer
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at org.apache.tomcat.service.connector.TcpConnector.receiveFully
(TcpConnector.java:150)
at org.apache.tomcat.service.connector.TcpConnector.receive
(TcpConnector.java:121)
at 
org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection
(Ajp13ConnectionHandler.ja
va:146)
at org.apache.tomcat.service.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run
(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:484)

After a while Tomcat starts failing to respond till it hangs completely.

I've seen Sun's JVM release and already set up the 'work around' parameters 
for Linux.

Any other hint ?

Thanks
Renato.

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

DO NOT REPLY [Bug 5096] - PageData.getInputStream() returns XML doc with invalid encoding

[bugzilla]

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

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

PageData.getInputStream() returns XML doc with invalid encoding

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 10:43 ---
Patch applied (nightly build 20011211).   Thanks Hans Bergsten for the patch.

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

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler XmlOutputter.java

[kinman]

kinman  01/12/10 10:23:00

  Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch XmlOutputter.java
  Log:
  PR: 5096
  Submitted by: Hans Bergsten
  
  - Use UTF-8 encoding for XML view of a JSP page.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.16.2.2  +10 -5 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java
  
  Index: XmlOutputter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
  retrieving revision 1.16.2.1
  retrieving revision 1.16.2.2
  diff -u -r1.16.2.1 -r1.16.2.2
  --- XmlOutputter.java 2001/10/09 17:56:42 1.16.2.1
  +++ XmlOutputter.java 2001/12/10 18:23:00 1.16.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
 1.16.2.1 2001/10/09 17:56:42 kinman Exp $
  - * $Revision: 1.16.2.1 $
  - * $Date: 2001/10/09 17:56:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
 1.16.2.2 2001/12/10 18:23:00 kinman Exp $
  + * $Revision: 1.16.2.2 $
  + * $Date: 2001/12/10 18:23:00 $
*
* 
*
  @@ -290,8 +290,13 @@
   append("jsp:root", rootAttrs, buff, false);
buff.append(sb.toString());
   buff.append("");
  - InputStream is = 
  - new ByteArrayInputStream(buff.toString().getBytes());
  +InputStream is = null;
  +try {
  +is = new ByteArrayInputStream(buff.toString().getBytes("UTF-8"));
  +}
  +catch (java.io.UnsupportedEncodingException e) {
  +// Can never happen? I assume all platforms support UTF-8
  +}
   //System.out.println("XmlOutputter: \n" + buff);
PageData pageData = new PageDataImpl(is);
   return pageData;
  
  
  

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

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler XmlOutputter.java

[kinman]

kinman  01/12/10 10:18:41

  Modified:jasper/src/share/org/apache/jasper/compiler
XmlOutputter.java
  Log:
  PR: 5096
  Submitted by: Hans Bergsten
  
  - Use UTF-8 encoding for XML view of a JSP page.
  
  Revision  ChangesPath
  1.18  +10 -5 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java
  
  Index: XmlOutputter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- XmlOutputter.java 2001/10/09 17:53:29 1.17
  +++ XmlOutputter.java 2001/12/10 18:18:41 1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
 1.17 2001/10/09 17:53:29 kinman Exp $
  - * $Revision: 1.17 $
  - * $Date: 2001/10/09 17:53:29 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
 1.18 2001/12/10 18:18:41 kinman Exp $
  + * $Revision: 1.18 $
  + * $Date: 2001/12/10 18:18:41 $
*
* 
*
  @@ -290,8 +290,13 @@
   append("jsp:root", rootAttrs, buff, false);
buff.append(sb.toString());
   buff.append("");
  - InputStream is = 
  - new ByteArrayInputStream(buff.toString().getBytes());
  +InputStream is = null;
  +try {
  +is = new ByteArrayInputStream(buff.toString().getBytes("UTF-8"));
  +}
  +catch (java.io.UnsupportedEncodingException e) {
  +// Can never happen? I assume all platforms support UTF-8
  +}
   //System.out.println("XmlOutputter: \n" + buff);
PageData pageData = new PageDataImpl(is);
   return pageData;
  
  
  

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

DO NOT REPLY [Bug 4964] - popBody() is called before doEndTag() is called in a BodyTag

[bugzilla]

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

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

popBody() is called before doEndTag() is called in a BodyTag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||tomcat-
   ||[EMAIL PROTECTED]
 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |

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

DO NOT REPLY [Bug 5318] - Default error page processing broken.

[bugzilla]

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

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

Default error page processing broken.





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 10:21 ---
This seems to be true with any ServletException Jasper throws, e.g. jsp
compilation errors.  Looks like a problem in the container.

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

DO NOT REPLY [Bug 4949] - jspc cannot find bean when using jsp:getProperty or jsp:setProperty

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4949>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

jspc cannot find bean when using jsp:getProperty or jsp:setProperty

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 10:13 ---
Fixed in nightly 20011210

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

DO NOT REPLY [Bug 4705] - Jasper seeming classpath bug using JSPC

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4705>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Jasper seeming classpath bug using JSPC

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 10:11 ---
Fixed in nightly build 20011210

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

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanRepository.java

[kinman]

kinman  01/12/10 09:48:24

  Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch BeanRepository.java
  Log:
  PR: 4705 and 4949
  - Use the correct class loader when loading a bean.  This fixed a problem
in jspc when processing jsp:setProperty.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.1   +8 -8  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java
  
  Index: BeanRepository.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  --- BeanRepository.java   2001/06/19 04:17:42 1.2
  +++ BeanRepository.java   2001/12/10 17:48:24 1.2.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.2 2001/06/19 04:17:42 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/06/19 04:17:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.2.2.1 2001/12/10 17:48:24 kinman Exp $
  + * $Revision: 1.2.2.1 $
  + * $Date: 2001/12/10 17:48:24 $
*
* 
* 
  @@ -84,6 +84,7 @@
   Vector appBeans;
   Vector requestBeans;
   Hashtable beanTypes;
  +ClassLoader loader;
   
   public BeanRepository (ClassLoader loader) {
sessionBeans = new Vector(11);
  @@ -91,6 +92,7 @@
appBeans = new Vector(11);
requestBeans= new Vector(11);
beanTypes= new Hashtable ();
  +this.loader = loader;
   }
   
   public boolean checkSessionBean (String s) {
  @@ -166,8 +168,7 @@
   throws ClassNotFoundException {
Class cls = null;
//try {
  - cls = Thread.currentThread().getContextClassLoader().loadClass
  -(clsname) ;
  + cls = loader.loadClass (clsname);
//} catch (ClassNotFoundException ex) {
//return false;
//}
  @@ -177,8 +178,7 @@
   public Class getBeanType (String bean) throws JasperException {
Class cls = null;
try {
  - cls = Thread.currentThread().getContextClassLoader().loadClass
  -((String)beanTypes.get(bean)) ;
  + cls = loader.loadClass ((String)beanTypes.get(bean));
} catch (ClassNotFoundException ex) {
throw new JasperException (ex);
}
  @@ -213,7 +213,7 @@
throws ClassNotFoundException {
Class cls = null;
if (clsname != null) {
  - cls = Thread.currentThread().getContextClassLoader().loadClass 
(clsname);
  + cls = loader.loadClass (clsname);
}
return cls;
   }
  
  
  

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

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler BeanRepository.java

[kinman]

kinman  01/12/10 09:43:16

  Modified:jasper/src/share/org/apache/jasper CommandLineContext.java
JspCompilationContext.java
   jasper/src/share/org/apache/jasper/compiler
BeanRepository.java
  Log:
  PR: 4705 and 4949
  - Use the correct class loader when loading a bean.  This fixed a problem
in jspc when processing jsp:setProperty.
  
  Revision  ChangesPath
  1.7   +4 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java
  
  Index: CommandLineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CommandLineContext.java   2001/02/08 13:36:56 1.6
  +++ CommandLineContext.java   2001/12/10 17:43:16 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
 1.6 2001/02/08 13:36:56 glenn Exp $
  - * $Revision: 1.6 $
  - * $Date: 2001/02/08 13:36:56 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/CommandLineContext.java,v
 1.7 2001/12/10 17:43:16 kinman Exp $
  + * $Revision: 1.7 $
  + * $Date: 2001/12/10 17:43:16 $
*
* 
* 
  @@ -164,7 +164,7 @@
   
   /**
* What class loader to use for loading classes while compiling
  - * this JSP? I don't think this is used right now -- akv. 
  + * this JSP?
*/
   public ClassLoader getClassLoader() {
   return loader;
  
  
  
  1.6   +4 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspCompilationContext.java
  
  Index: JspCompilationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspCompilationContext.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JspCompilationContext.java2001/02/08 13:37:16 1.5
  +++ JspCompilationContext.java2001/12/10 17:43:16 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspCompilationContext.java,v
 1.5 2001/02/08 13:37:16 glenn Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/02/08 13:37:16 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspCompilationContext.java,v
 1.6 2001/12/10 17:43:16 kinman Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/12/10 17:43:16 $
*
* 
* 
  @@ -101,7 +101,7 @@
   
   /**
* What class loader to use for loading classes while compiling
  - * this JSP? I don't think this is used right now -- akv. 
  + * this JSP?
*/
   public ClassLoader getClassLoader();
   
  
  
  
  1.3   +8 -8  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java
  
  Index: BeanRepository.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- BeanRepository.java   2001/06/19 04:17:42 1.2
  +++ BeanRepository.java   2001/12/10 17:43:16 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.2 2001/06/19 04:17:42 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/06/19 04:17:42 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/BeanRepository.java,v
 1.3 2001/12/10 17:43:16 kinman Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/12/10 17:43:16 $
*
* 
* 
  @@ -84,6 +84,7 @@
   Vector appBeans;
   Vector requestBeans;
   Hashtable beanTypes;
  +ClassLoader loader;
   
   public BeanRepository (ClassLoader loader) {
sessionBeans = new Vector(11);
  @@ -91,6 +92,7 @@
appBeans = new Vector(11);
requestBeans= new Vector(11);
beanTypes= new Hashtable ();
  +this.loader = loader;
   }
   
   public boolean checkSessionBean (String s) {
  @@ -166,8 +168,7 @@
   throws ClassNotFoundException {
Class cls = null;
//try {
  - cls = Thread.currentThread().getContextClassLoader().loadClass
  -(clsname) ;
  + cls = loader.loadClass (clsname);
//} catch (ClassNotFoundException ex) {
//return false;
//}
  @@ -177,8 +178,7 @@
   public Class getBeanType (String bean) throws JasperE

Tomcat 4.01 CRITICAl ERROR in ServletInputStream implementation

[Gyorgy Gyepesi]

URGENT PLEASE SEND REPLY ASAP!!

The ServletInputStream implementation reports EOF once a byte of value 0xff
appears in the request body (of content-type application/octet-stream
without content-endcoding); the probable cause is the following line in

org.apache.catalina.connector.warp.WarpRequest:

if (this.packet.pointerhttp://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apac
he/catalina/connector/warp/WarpRequest.java?rev=1.8&content-type=text/vnd.vi
ewcvs-markup
)

This behaviour MAKES Tomcat UNUSABLE for clients sending binary data in the
POST request body.

Regards

Gyorgy




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

DO NOT REPLY [Bug 5343] New: - taglib-location doesn't accept an '/' as first character

[bugzilla]

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

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

taglib-location doesn't accept an '/' as first character

   Summary: taglib-location doesn't accept an '/' as first character
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows 9x
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In a web.xml file, I have this tag library.
--


http://www.my.com/tags


/WEB-INF/my.tld


--


When Tomcat starts, shows this error...
-
PARSE error at line 1 column -1
org.xml.sax.SAXParseException: org.apache.crimson.parser/V-005 taglib
-


If I delete the '/' before WEB-INF, I get no error starting Tomcat, but when I 
send a request to a .jsp page that use this tag, I get a Tomcat Exception...

--
Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error

type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) 
that prevented it from fulfilling this request.

exception 

org.apache.jasper.JasperException: JSP File "/WEB-INF/WEB-INF/my.tld" not found
at org.apache.jasper.compiler.TagLibraryInfoImpl.
(TagLibraryInfoImpl.java:214)
at 
org.apache.jasper.compiler.JspParseEventListener.processTaglibDirective
(JspParseEventListener.java:1161)
at org.apache.jasper.compiler.JspParseEventListener.handleDirective
(JspParseEventListener.java:755)
at org.apache.jasper.compiler.DelegatingListener.handleDirective
(DelegatingListener.java:121)
at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:243)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1133)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1091)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1087)
at org.apache.jasper.compiler.ParserController.parse
(ParserController.java:213)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:210)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:546)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary
(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
(JspServlet.java:189)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:462)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPip

Re: AJP Todo

[Incze Lajos]

On Sun, Dec 09, 2001 at 08:24:35PM -0800, Bill Barker wrote:
...
> (b) For a context defined in the server.xml, there seems to be no public way
> to determine the document base as an absolute path.  This may just be my
> lack of familiarity with Catalina however.  On a related note, I wasn't able
> to find any way to determine if a Context even has a document base (as
> opposed to a war file).
> 
What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3)

getRealPath

public java.lang.String getRealPath(java.lang.String path)

Returns a String containing the real path for a given virtual path.
For example, the path "/index.html" returns the absolute file path
on the server's filesystem would be served by a request for
"http://host/contextPath/index.html";, where contextPath is the context
path of this ServletContext..

The real path returned will be in a form appropriate to the computer and
operating system on which the servlet container is running, including the
proper path separators. This method returns null if the servlet container
cannot translate the virtual path to a real path for any reason (such as
when the content is being made available from a .war archive).
-
So, getServletContext().getRealPath( "/" )

incze

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

DO NOT REPLY [Bug 5339] - Please add example JSP page in XML format

[bugzilla]

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

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

Please add example JSP page in XML format





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 07:55 ---
Created an attachment (id=884)
Example JSP page in XML format

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

DO NOT REPLY [Bug 5339] New: - Please add example JSP page in XML format

[bugzilla]

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

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

Please add example JSP page in XML format

   Summary: Please add example JSP page in XML format
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Please add an example JSP page that is formatted using the XML format.

Such an example will highlight Tomcat 4 support for JSP 1.2.

While not very creative, I've attached a simple example of such a page that I
developed after I didn't find one in the webapps/examples directory,

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

DO NOT REPLY [Bug 4801] - Many documents included with webapps 4.0.1 RPM are zero length

[bugzilla]

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

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

Many documents included with webapps 4.0.1 RPM are zero length





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 07:44 ---
It also appears that several of the image filse have been corrupted.

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

Re: Strange Thread Behaviour

[Remy Maucherat]

> It seems like tomcat has no control about the threads that were opened,
>
> any suggestions, please?

Yes, no attempt is being made at killing processing threads that were
created. OTOH, they should be reused if some high load situation occurs
again (no new threads will be created).
Unless you're really short on OS resources, I don't see that being a huge
problem.

Remy


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

Strange Thread Behaviour

[Ferran Arís]

Hi everybody!

I have a strange problem with Tomcat Version 4.0.1 running on GNU/Linux Debian Kernel 
2.2.19 using j2sdk 1.3.1 from blackdown.

I have a JSP page that returns a simple 1 in simple text page format, no HTTPsession.

You start tomcat normally and the HTTPconnector running at port 80 standalone has 

minProcessors=5 maxProcessors=15

It starts 20 linux java processes and i can see that in the logs he open the 5 initial 
background threads.

Until now everything is OK.

When you start calling the JSP page everything is OK. if you get mad and you call this 
page over and over again very fast everything is ok but after a while beggins to open 
new background threads for incoming requests, this is also ok, maybe he has no time to 
process the lot of requestes with 5 threads. The number of OS processes beggins to 
grow for every background thread he opens, also no problem. Then i stop to ask for the 
page, everything ok normally after a while he should stop the background processes 
when the connection times out (connectionTimeout=15000) so i wait about 3 hours. After 
this, the number of java processes it's still the same and in the logs it doesn't come 
nothing like (Stopping background thread) so i begin to call the page again and again. 
When the number again the number of processes begin to grow until Tomcat stops 
responding. After this "catalina.sh stop" is not able to end tomcat i must "kill pid" 
of the first java process otherwise java processes are always opened.

It seems like tomcat has no control about the threads that were opened,

any suggestions, please?

Ferran

Re: AJP Todo

[Remy Maucherat]

> >
> > If the web app is deployed as a directory, you can call
> > context.getDocBase() for this.  If the context is deployed as a WAR
file,
> > there is no such thing as the "document base as an absolute path".  In
> > such a scenario, you need to choose one of the following options:
> Unfortunately, if the context is declared in server.xml, getDocBase
returns
> the docBase declared in server.xml (e.g. "examples" in the shipping
> server.xml).  I can't see how to turn this into an absolute path.
> >
> > * Forward *all* requests to Tomcat for processing
> This is my preference.  The problem is determining if it is deployed as a
> WAR file or not given the context.  This one is probably just my stupidity
> however :).

You should be able to use Context.getResource and then use instanceof to see
if it's a FileDirContext, a WARDirContext or something else altogether (in
which case, you should do the same as if it was a WAR, I think).

> > * Reject a webapp that is deployed this way

Please don't do that :)

Remy


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

DO NOT REPLY [Bug 5112] - tomcat4 rpm missing doc files

[bugzilla]

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

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

tomcat4 rpm missing doc files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 02:17 ---
*** Bug 5315 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 5315] - Unable to connect remote server

[bugzilla]

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

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

Unable to connect remote server

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 02:17 ---
That particular issue has already been reported, and should be fixed in the 
next RPM release.

*** This bug has been marked as a duplicate of 5112 ***

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

Re: [Vote] New committer: Eric Rescorla

[jean-frederic clere]

+1

GOMEZ Henri wrote:
> 
> As you may know, Eric Rescorla is one the few specialists in SSL
> in the world, author of one of the few SSL bible books and he have
> also created the excellent OpenSource JSSE alternative, PureTLS.
> 
> He strike back in adapting PureTLS to Tomcat, today Tomcat 3.3, and
> so I would like to propose him as a new committer.
> 
> Votes please?
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

RE: JK2: Configuration(1)

[GOMEZ Henri]

>> Seems like I was reinventing the wheel there for a while. So 
>AJP14 knows
>> how configure itself from the running Tomcat... Pretty cool 
>in my book!
>
>Yes, Henri has added quite a bit of code for that. I did few changes to
>make the 'autoconf' usable with other workers and more 'exposed' - see
>jk_webapp, jk_uriEnv.

As usually costin make a remarquable cleaning here :)

>And this will remain and will be enhanced - we want tomcat to 
>be able to
>send notifications like 'webapp reload' or 'webapp down', etc.
>
>Or the reverse - apache to send this to the workers in the farm (
>assuming a 'central' tomcat or after a soft restart of apache ).

>The major problems and why I don't think this can be the only way:
>- it requires tomcat to be started

We could keep a copy of the latest known configuration and fall back
to this one if the 'Tomcat Master Repository' is not available at
start time. Which make me think that we should add some mecanism to let
a tomcat announce itself when it wake up, not so easy till we have a
true multithreading WebServer...

>- it's not very clear how it'll work for a complex case ( many workers,
>some apps replicated, some not ). It's hard to imagine how to 
>do that in
>general, having it automated and on the wire is too much.

A simple mecanism could be to for 'at best discovery' in web-server.
ie in main or virtual hosts part of httpd.conf (and corresponding
IIS/iPlanet)
to have a :

JkAutoMount * worker (which will means, grab ALL the revelant webapps for
this
virtualhost instance). 

>- it's hard to 'tune'. I think we are at an early stage, where we still
>learn how people are using tomcat/apache. With few scripts you can do a
>lot - like rsync webapps/, generate 'native' configs, insert special
>settings.

Sure...

>> > The problems with 'tomcat sending config info to apache' ( 
>and why I
>> > would not make that the 'default' simple config ):
>> >
>> > 1. It requires a strict startup sequence ( tomcat before apache ).
>> > Otherwise, if tomcat is not started apache will respond '404' for
>> > what it doesn't recognize, instead of 'temporary 
>unavailable' or 'context
>> > is down'. This can be very problematic for users ( who'll 
>assume the url
>> > is wrong instead of try again later ).
>>
>> This is easily achieved (that's how I run my boxes) through 
>the startup
>> script when both Apache and Tomcat are on the same box. I call this
>> thing 'was' -> Web Application Server. Here is the sample (RH Linux
>> 7.0):
>
>On a complex site, Apache will probably server more that java 
>pages - and
>talk with more than a single tomcat.

Yes, Apache talking with a farm of tomcat using load-balancing mode.
But we assume that all tomcat's have the same webapps installed.

>Having a file-hierarchy based system can allow delegation ( change the
>permissions on a dir and let a group manage an 
>application/vhosts ), etc.
>Things that would be hard to do if we rely only on a wire 
>protocol ( or at
>least hard to do in the next 2-3 months, after we gain more 
>experience I'm
>sure we can do it )

Yes, let's put jk2 to life quickly, add stuff in protocol,
(to be implemented latter).

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

RE: JK2: Configuration(1)

[GOMEZ Henri]

>> To clarify - this is not a replacement or an 'exclusive' mechanism.
>> The 'ajp14' based config, where tomcat sends notifications to apache
>> remains.
>
>Seems like I was reinventing the wheel there for a while. So 
>AJP14 knows
>how configure itself from the running Tomcat... Pretty cool in my book!

That was one of the important evolution of ajp14 in regard of ajp13.

>> The problems with 'tomcat sending config info to apache' ( and why I
>> would not make that the 'default' simple config ):
>> 
>> 1. It requires a strict startup sequence ( tomcat before apache ).
>> Otherwise, if tomcat is not started apache will respond '404' for
>> what it doesn't recognize, instead of 'temporary 
>unavailable' or 'context
>> is down'. This can be very problematic for users ( who'll 
>assume the url
>> is wrong instead of try again later ).
>
>This is easily achieved (that's how I run my boxes) through the startup
>script when both Apache and Tomcat are on the same box. I call this
>thing 'was' -> Web Application Server. Here is the sample (RH Linux
>7.0):

Pretty the same stuff in my RPM for TC 3.3 :)

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

DO NOT REPLY [Bug 5315] - Unable to connect remote server

[bugzilla]

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

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

Unable to connect remote server





--- Additional Comments From [EMAIL PROTECTED]  2001-12-10 01:34 ---
It's happend when I installed tomcat-4.0.1 from rpm and accessing taglibs where 
tomcat-4.0.1 tar.gz is working fine.

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

RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt

[GOMEZ Henri]

Did you also include the requirement on Cryptix and cryptix asn ?
Nota that the cryptix-asn to be used is a patched version of 
the 'official'.

from puretls announce :

==>

DEPENDENCIES
JDK:
PureTLS has been developed under JDK 1.1.8 on FreeBSD. It 
has been tested under JDK 1.2 on Solaris and Windows.

Cryptix:
Although PureTLS includes some crypto functionality (DH and DSS
implementations) it depends on Cryptix for a number of algorithms
(RSA, MD5, SHA-1, DES, 3DES, RC4, RC2). It would be nice if any
JCE-compliant provider would work and we'll work on that for future
releases, but for the moment, Cryptix is required. The issue is that
key formats are not standardized and we depend on Cryptix-specific
formats. 

The latest version of Cryptix (3.2) can be obtained at:
http://www.cryptix.org/

pCryptix ASN.1 kit:
PureTLS uses the Cryptix ASN.1 kit for it's certificate and key parsing.
Due to version skew you need to get a modified version from
http://www.rtfm.com/puretls
This version is known to work.

<==

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Friday, December 07, 2001 6:37 AM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt
>
>
>billbarker01/12/06 21:36:39
>
>  Modified:.RELEASE-NOTES-3.3.1.txt
>  Log:
>  Document PureTLS support.
>  
>  Revision  ChangesPath
>  1.11  +4 -1  jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
>  
>  Index: RELEASE-NOTES-3.3.1.txt
>  ===
>  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
>  retrieving revision 1.10
>  retrieving revision 1.11
>  diff -u -r1.10 -r1.11
>  --- RELEASE-NOTES-3.3.1.txt  2001/12/05 11:29:50 1.10
>  +++ RELEASE-NOTES-3.3.1.txt  2001/12/07 05:36:39 1.11
>  @@ -3,7 +3,7 @@
>Release Notes
>=
>   
>  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.10 2001/12/05 11:29:50 larryi Exp $
>  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.11 2001/12/07 05:36:39 
>billbarker Exp $
>   
>   
>   This document describes the changes that have been made since the
>  @@ -41,6 +41,8 @@
>Moved the setting of the default "*.jsp" mapping so 
>that it is now 
>possible to entirely disable support for jsp files.
>   
>  + Fixed problem with jsp_precompile parameter to JSP files.
>  +
>Context properties and ContextManager properties 
>can now be set with
> elements, i.e: 
>
>  @@ -51,6 +53,7 @@
>variable substitution to be used in 
>declarations.
>   
>  + Added support for PureTLS as an SSL option.
>   
>   Server:
>   
>  
>  
>  
>
>--
>To unsubscribe, e-mail:   
>
>For 
>additional commands, e-mail: 
>
>

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

RE: JK2: Configuration(1)

[GOMEZ Henri]

>On Fri, 7 Dec 2001, GOMEZ Henri wrote:
>
>> Caution, caution with security.
>>
>> On many sites, the web-server is located on a DMZ so subject
>> to be hacked, while the Tomcats are behind firewall. Having
>> webapp (program) could raise many problems.
>
>Hmm... I hope sandboxing is used for tomcat in this case...

The problem is not sandboxing but really that a web-server is 
often in a low-security zone and should be considered as possibly
compromized. You could have the static part of a webapp there since
it's a low risk of application discovery but the dynamic part, 
jsp/servlet/struts's/velocity's/... should be located elsewhere
and ideally behind a firewall accepting only ajp communication 
between web-server and tomcat's.

>> INTERNET ---> FW ---> APACHE HTTP -> FW (only ajp13) -> TOMCAT's
>>
>> Why not imagine that Apache will ask to Tomcat, may be to a
>> tomcat tagged a master repository, to be send all the WEBAPPS
>> infs ?
>
>As I said in a previous mail, startup sequence is one big problem.

The idea of having one tomcat on a farm of tomcat as the master 
repository of webapp will even ease the deployment of application.

- Put new or updated webapps in master repository
- Apache discover updates or creation and update URL mapping accordingly.
- Apache could then ask to the master repository to have a copy (may be a 
  .war) of updated/created webapp
- Apache then 'upload' the webapp to other tomcats.

To enforce security, WEBAPP wars should be encrypted using a key known only
by
tomcats, that way even if the webserver is compromized, hacker couldn't
decrypt the webapp.

>The other - I believe it's simpler. Apps must be deployed on apache as
>well, or at least the static content ( and with my proposal
>WEB-INF/jk.properties ).

That's ok for me...

>> >mod_jk will use the same logic as tomcat to find all subdirs,
>> >and automatically add the contexts. ( using 'global' mappings )
>>
>> Why not, I'll be more than happy to remove workers.properties and
>> have it included in httpd.conf. Good things will be to map
>> VirtualHost to remote Virtual on Tomcat.
>
>Well... I already added code to allow use of httpd.conf instead of
>workers.properties ( I use it for development, so I don't have 
>to change 2
>files ).

Good, did the IIS/iPlanet port could use the same mecanism ?

>Virtual hosts are a problem I'm trying to resolve - the current mapper
>doesn't seem to have that, not sure how it works on IIS/iPlanet.

Do you means that a VirtualHost entry on Apache should ask only
for revelant VirtualHost webapps in tomcat ? In ajp14 the virtual
host id was the key of autoconf requests.

>Regarding my proposal, we can either use 3.3 non-flat webapps/
>( i.e webapps/virtual.host/app ) or have a webapp dir per virtual host,
>specified with either
> JkWebapps /webapps1 whost1.com
>
>or inside a  directive.


>> >- no need to have tomcat running ( or running on
>> >the server machine )
>>
>> For security reason, i'd like to avoid having webapp code
>> (servlet/jsp) on the web-server. And if tomcat is not
>> running (locally or remotly), did there is a need to
>> do a collect of webapp ?
>
>For servlets - you can remove them from apache if you want. For jsps -
>they could be removed, but ( when I'll have time... ) I want to try
>sending the static content of the jsp using apache. It may 
>work or not -
>but I think it's worth trying, and if it works the way I 
>expect it should
>have a good performance benefit.

Static part handled by Apache and dynamic by tomcat, and having
Apache mix the both before sending back to users ? 
A great performance gain...

>> Could we discuss about a Tomcat 3.3 running as a webapp
>> repositories manager ?
>
>Or in general a config server ? I.e. a server ( tomcatX, 
>apache, OpenLDAP,
>database ) where all configs are stored and the workers
>get it automatically ?

configs and webapps, a common place for webapps stuff.

>Yes, that would be nice - but I think it's more dream-level at this
>moment, most people have problems with configuring the simple case.

Not sure it will be much difficult by using tomcat in autoconf.
ajp14 added URL/webapp discovery, we should add the webapp 
download (tomcat->apache) and then webapp uploading (apache->tomcats)
to make the dream a reality.

The sofisticated ORB model you're developp in jk2 should make it
more easy and we should reserve these capacity in ajp14 protocol...

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