DO NOT REPLY [Bug 11187] - Question on request.getHeaderNames()

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

Question on request.getHeaderNames()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[luehe]

luehe   2002/07/25 15:28:46

  Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
   jasper2/src/share/org/apache/jasper/compiler Parser.java
TagFileProcessor.java TagLibraryInfoImpl.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Added:   jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java
  Log:
  Added support for implicit tag libraries containing the tag handlers of tag files 
stored in a directory without a TLD file
  
  Revision  ChangesPath
  1.10  +12 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
  
  Index: JspCompilationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JspCompilationContext.java24 Jul 2002 09:09:47 -  1.9
  +++ JspCompilationContext.java25 Jul 2002 22:28:45 -  1.10
  @@ -61,19 +61,16 @@
   
   package org.apache.jasper;
   
  +import java.io.*;
  +import java.net.*;
  +import java.util.Set;
  +import javax.servlet.ServletContext;
  +import org.apache.jasper.compiler.JspRuntimeContext;
   import org.apache.jasper.compiler.JspReader;
   import org.apache.jasper.compiler.ServletWriter;
  -import java.io.IOException;
  -import java.io.File;
  -import java.io.FileNotFoundException;
  -import java.net.URL;
  -import java.net.URLClassLoader;
  -import java.net.MalformedURLException;
   import org.apache.jasper.compiler.Compiler;
   import org.apache.jasper.servlet.JspServletWrapper;
   import org.apache.jasper.servlet.JasperLoader;
  -import javax.servlet.ServletContext;
  -import org.apache.jasper.compiler.JspRuntimeContext;
   
   /**
* A place holder for various things that are used through out the JSP
  @@ -233,6 +230,10 @@
   
   public URL getResource(String res) throws MalformedURLException {
   return context.getResource(canonicalURI(res));
  +}
  +
  +public Set getResourcePaths(String path) {
  +return context.getResourcePaths(canonicalURI(path));
   }
   
   /** 
  
  
  
  1.13  +25 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Parser.java   25 Jul 2002 19:02:16 -  1.12
  +++ Parser.java   25 Jul 2002 22:28:45 -  1.13
  @@ -368,13 +368,28 @@
Attributes attrs = parseAttributes();
String uri = attrs.getValue("uri");
String prefix = attrs.getValue("prefix");
  - if (uri != null && prefix != null) {
  - // Errors to be checked in Validator
  - String[] location = ctxt.getTldLocation(uri);
  - TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, parserController,
  -prefix, uri, location,
  -err);
  - taglibs.put(prefix, tl);
  + if (prefix != null) {
  + TagLibraryInfo tagLibInfo = null;
  + if (uri != null) {
  + // Errors to be checked in Validator
  + String[] location = ctxt.getTldLocation(uri);
  + tagLibInfo = new TagLibraryInfoImpl(ctxt, parserController,
  + prefix, uri, location,
  + err);
  + } else {
  + String tagdir = attrs.getValue("tagdir");
  + if (tagdir != null) {
  + tagLibInfo = ImplicitTagLibraryInfo.getTabLibraryInfo(
  +ctxt,
  + parserController,
  + prefix, 
  + tagdir,
  + err);
  + }
  + }
  + if (tagLibInfo != null) {
  + taglibs.put(prefix, tagLibInfo);
  + }
}
   
new Node.TaglibDirective(attrs, start, parent);
  
  
  
  1.3   +12 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u 

tomcat in 64-bit mode

[Ed Borkmann]

Tomcat4.0 ran fine until we started running it with the 64 bit option
-d64 

We are using Solaris 2.8  on a Sun-Fire-280R.

Now Tomcat will crash every few hours.  Does anybody know of a reason why this 
would happen?  The logs really don't give any clues.
Thanks.

Ed




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

DO NOT REPLY [Bug 11183] New: - ArrayIndexOutOfBoundsException in parseParameters()

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

ArrayIndexOutOfBoundsException in parseParameters()

   Summary: ArrayIndexOutOfBoundsException in parseParameters()
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When submitting a JSP request in which the value of the LAST parameter on the 
URL ends in a percent sign, Catalina throws a 
"java.lang.ArrayIndexOutOfBoundsException" in the parseParameters() method of 
org.apache.catalina.util.RequestUtil. 

Looking at the following line from the switch statement, it would seem that the 
code is assuming there are two more characters after the percent sign:

case '%':
data[ox++] = (byte)((convertHexDigit(data[ix++]) << 4)
+ convertHexDigit(data[ix++]));

If the query string were properly encoded (% -> %25), this wouldn't be an issue.  
But if it's not, shouldn't the container handle it better than this exception?

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

DO NOT REPLY [Bug 11181] New: - HelloWorldExample doesnt compile

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

HelloWorldExample doesnt compile

   Summary: HelloWorldExample doesnt compile
   Product: Tomcat 4
   Version: 4.1.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


public class HelloWorldExample extends HttpServlet 
{
public void doGet(HttpServletRequest request,
  HttpServletResponse response)
throws IOException, ServletException
{
ResourceBundle rb =
ResourceBundle.getBundle("LocalStrings",Locale.getDefault
()); //request.getLocale());
response.setContentType("text/html");
//HttpServletRequest has no getLocale() method...

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

Re: javax.servlet.jsp.el.ExpressionEvaluator ????

[Kin-Man Chung]

The head branch of jasper2 is meant to be part of Jakarta-tomcat-5, which
in the middle of being set up.  It might be a while before tomcat 5
can be built.

You should check out the tomcat_4_branch of jasper2 for your build.

If you really want to build Jakarta-tomcat-4 with the head branch
of jasper2 with, just to try out JSP2.0 features, then you should
follow the instructions in BUILDING.txt in jasper2.


> Date: Thu, 25 Jul 2002 14:45:07 -0500
> From: Brian Millett <[EMAIL PROTECTED]>
> Subject: javax.servlet.jsp.el.ExpressionEvaluator 
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Content-transfer-encoding: 7bit
> 
> I am trying to compile the latest 7/25 cvs co of Jakarta-tomcat-4 and I
> have ran into a problems with jasper2.
> 
>[javac]
> 
/home/bpm/compile_area/cvs_jakarta/jakarta-tomcat-jasper/jasper2/src/share/org/a
pache/jasper/compiler/JspUtil.java:90: package javax.servlet.jsp.el does not 
exist
> [javac] import javax.servlet.jsp.el.ExpressionEvaluator;
> [javac] ^
> 
> 
> I have no idea where this file might be located.  It is not part of the
> commons, commons-sandbox, taglibs, struts, velocity, etc.
> 
> What is it and why was code committed to CVS that references files that
> do not exist?
> 
> Thanks.
> 
> -- 
> Brian Millett
> Enterprise Consulting Group "Shifts in paradigms
> (314) 205-9030 often cause nose bleeds."
> [EMAIL PROTECTED]   Greg Glenn
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

javax.servlet.jsp.el.ExpressionEvaluator ????

[Brian Millett]

I am trying to compile the latest 7/25 cvs co of Jakarta-tomcat-4 and I
have ran into a problems with jasper2.

   [javac]
/home/bpm/compile_area/cvs_jakarta/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java:90:
 package javax.servlet.jsp.el does not exist
[javac] import javax.servlet.jsp.el.ExpressionEvaluator;
[javac] ^


I have no idea where this file might be located.  It is not part of the
commons, commons-sandbox, taglibs, struts, velocity, etc.

What is it and why was code committed to CVS that references files that
do not exist?

Thanks.

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


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

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

[luehe]

luehe   2002/07/25 12:08:46

  Modified:jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java
  Log:
  Removed java.lang.Exception from throws clause of TagFileProcessor.parseTagFile()
  
  Revision  ChangesPath
  1.2   +3 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TagFileProcessor.java 24 Jul 2002 22:38:43 -  1.1
  +++ TagFileProcessor.java 25 Jul 2002 19:08:46 -  1.2
  @@ -278,7 +278,7 @@
   }
   
   public static TagInfo parseTagFile(ParserController pc, String tagfile)
  -throws FileNotFoundException, JasperException, Exception {
  +throws FileNotFoundException, JasperException {
   
   Node.Nodes page = pc.parse(tagfile);
   TagFileVisitor tagFileVisitor = new TagFileVisitor(pc.getCompiler());
  
  
  

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

DO NOT REPLY [Bug 11177] - Tomcat requires JRE 1.2 on Solaris 2.7

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

Tomcat requires JRE 1.2 on Solaris 2.7

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Version|3.1 Final   |3.3.1 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 19:04 ---
This is fixed in the nightly.

In the mean time, you can work around it by running Tomcat as:

TOMCAT_OPTS=-Dtomcat.install=/home/b0fds_ws/atlas startup.sh

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

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

[luehe]

luehe   2002/07/25 12:02:16

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java Parser.java
TagLibraryInfoImpl.java
  Log:
  Integrated TagFileProcessor into TagLibraryInfo constructor
  
  Revision  ChangesPath
  1.9   +5 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JspDocumentParser.java24 Jul 2002 19:58:57 -  1.8
  +++ JspDocumentParser.java25 Jul 2002 19:02:16 -  1.9
  @@ -483,8 +483,8 @@
   // get the location
   String[] location = ctxt.getTldLocation(uri);
   
  -tl = new TagLibraryInfoImpl(ctxt, prefix, uri, location,
  - err);
  +tl = new TagLibraryInfoImpl(ctxt, parserController, prefix,
  + uri, location, err);
   }
taglibs.put(prefix, tl);
}
  
  
  
  1.12  +6 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Parser.java   22 Jul 2002 20:35:27 -  1.11
  +++ Parser.java   25 Jul 2002 19:02:16 -  1.12
  @@ -371,8 +371,9 @@
if (uri != null && prefix != null) {
// Errors to be checked in Validator
String[] location = ctxt.getTldLocation(uri);
  - TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, prefix, uri,
  -location, err);
  + TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, parserController,
  +prefix, uri, location,
  +err);
taglibs.put(prefix, tl);
}
   
  
  
  
  1.5   +51 -13
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- TagLibraryInfoImpl.java   22 Jul 2002 23:02:55 -  1.4
  +++ TagLibraryInfoImpl.java   25 Jul 2002 19:02:16 -  1.5
  @@ -81,13 +81,14 @@
* @author Kin-man Chung
*/
   public class TagLibraryInfoImpl extends TagLibraryInfo {
  -static private final String TAGLIB_TLD = "META-INF/taglib.tld";
  -static private final String WEB_XML = "/WEB-INF/web.xml";
   
  -Hashtable jarEntries;
  +private static final String TAGLIB_TLD = "META-INF/taglib.tld";
  +private static final String WEB_XML = "/WEB-INF/web.xml";
   
  -JspCompilationContext ctxt;
  -ErrorDispatcher err;
  +private Hashtable jarEntries;
  +private JspCompilationContext ctxt;
  +private ErrorDispatcher err;
  +private ParserController parserController;
   
   private final void print(String name, String value, PrintWriter w) {
   if (value != null) {
  @@ -141,14 +142,19 @@
  
   }
   
  -public TagLibraryInfoImpl(JspCompilationContext ctxt, String prefix, 
  -   String uriIn, String[] location,
  -   ErrorDispatcher err) 
  -throws JasperException {
  -
  +/**
  + * Constructor.
  + */
  +public TagLibraryInfoImpl(JspCompilationContext ctxt,
  +   ParserController pc,
  +   String prefix, 
  +   String uriIn,
  +   String[] location,
  +   ErrorDispatcher err) throws JasperException {
   super(prefix, uriIn);
   
this.ctxt = ctxt;
  + this.parserController = pc;
this.err = err;
   ZipInputStream zin;
   InputStream in = null;
  @@ -275,6 +281,8 @@
   this.tagLibraryValidator = createValidator(element);
   else if ("tag".equals(tname))
   tagVector.addElement(createTagInfo(element));
  +else if ("tag-file".equals(tname))
  +tagVector.addElement(createTagInfoFromTagFile(element));
   else if ("function".equals(t

DO NOT REPLY [Bug 11177] New: - Tomcat requires JRE 1.2 on Solaris 2.7

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

Tomcat requires JRE 1.2 on Solaris 2.7

   Summary: Tomcat requires JRE 1.2 on Solaris 2.7
   Product: Tomcat 3
   Version: 3.1 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Config
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On JRE "Solaris_JDK_1.1.7_08a" Tomcat dies while starting with a 
java.lang.ClassNotFoundException: org.apache.tomcat.startup.EmbededTomcat 

If I use Solaris_JDK_1.2.2_11 it starts fine.

System Configuration:  Sun Microsystems  sun4u Sun Enterprise 450 (4 X 
UltraSPARC-II 400MHz)
Memory size: 2048 Megabytes

Solaris
Release: 5.7
Kernel architecture: sun4u
Application architecture: sparc
Hardware provider: Sun_Microsystems
Domain: 
Kernel version: SunOS 5.7 Generic 106541-15 January 2001


Complete error msg:
Using classpath: /home/b0fds_ws/atlas/lib/tomcat.jar
Using JAVA_HOME: /usr/java1.1
Using TOMCAT_HOME: /home/b0fds_ws/atlas

Jdk11Compat: Installing jar protocol handler 
Guessed home=/home/b0fds_ws/atlas/lib
Exception: java.lang.ClassNotFoundException: 
org.apache.tomcat.startup.EmbededTomcat
java.lang.ClassNotFoundException: org.apache.tomcat.startup.EmbededTomcat
at java.lang.Throwable.(Compiled Code)
at java.lang.Exception.(Compiled Code)
at java.lang.ClassNotFoundException.(Compiled Code)
at org.apache.tomcat.util.compat.SimpleClassLoader.loadClass(Compiled 
Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at org.apache.tomcat.startup.Main.execute(Compiled Code)
at org.apache.tomcat.startup.Main.main(Compiled Code)

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

[Logging] more issues with stack reading

[costinm]

Ok, back to the subject of extracting the method name from the 
stack trace.

The problem is actually a bit more complicated and I think we're
doing the wrong thing at the moment, and all proposed solutions
are quite bad.

What we are trying to solve: display the method and classname that
makes the log call. 

Log4j and jdk1.4 logging provide a config format to enable displaying this 
- logkit doesn't seem to, so it's not a problem there ( since it couldn't
be displayed in the first place - if it does, same issue as in jdk1.4 
apply )

Log4j has the best support for this - if you enable the display for
method and classname it'll generate a Throwable and walk the stack to
find the caller. It also have support for passing a Object which is 
indicates the 'wrapper' - so if log4j is wrapped, we display the real
caller, not the wrapper.

JDK1.4 does almost the same thing - if called directly and if the
method display is configured, it'll walk the stack. It is also possible
to pass the class/method as String params ( as oposed to log4j 
where you pass the Object wrapper ).

The problem in JDK1.4 is that there is no good way to deal with the 
case when their logger is wrapped ( by commons-logging or by a tomcat
logger or any other method ). So we have to 'emulate' this and extract
the information from stack in the wrapper. We could ask the user
to pass this explicitely - but that's stupid, since the info is redundant
( we already _have_ it, in the stack ) and make the logger hard to use.

We solve the problem for commons-logging, but what if commons-logging
itself is wrapped ? Well, same solution as in log4j can be used here, 
i.e. pass ( somehow ) information about the wrapper and skip it from
the stack walk.

However there are 2 huge problems:

1. Performance. Generating an exception and parsing the stack trace
is _extremely_ expensive. If you need the information - you'll have 
to pay for it, but the problem is that you pay for it even if you
_don't_ use it. 

2. Configuration. We either add explicit API to pass this info in each
Log method or we allow to configure it per LogFactory or once per Log
( i.e. a single method - generic or not - to configure it ). 

What that means is that in order to avoid the performance when it is
not needed, we also need to request the logger to enable stack checking
in 1.4 ( again, log4j works without problems anyway ). 

The solution of casting or constructing Jdk14Logger explicitely is 
wrong - we loose the pluggability and discovery. 

IMHO the only way to deal with that is to allow some form of 
configuration ( hints ) that is generic to all loggers. 

I'll ask for a vote - after I hear your comments. The hints 
will be passed by whoever creates the Logger, and so far the 
best solution seems to be setAttribute in Logger.

There is one alternative - that doesn't require API changes, and it
may be much better: 

Require ( or recomend ? ) that each Log and LogFactory to support a form 
of JMX. 

That would mean that we'll be able to find if a Log or LogFactory support
configuration, pass configuration using a standard API, use the 
existing JMX support in log4j, get the loggers to integrate nicely
in tomcat and apps that use JMX. 

A static MBean would be the best choice for this case - as it 
doesn't introduce _any_ dependency on JMX, it's just a programming
style where each LogFactory/Log impl would also implement an interface
with getters/setters. For log4j we could expose the 'real' MBean 
of the Category, since it already exist and get access to all
the config capabilities. 

Yet another alternative is to just use getter/setters and the 
introspection-based dynamic MBean in tomcat-util ( which can be used
to transparently enable any bean as a JMX component - like 3.3 
interceptors or jk handlers ).

I hope at least someone has read all this long message and will respond 
:-)

Costin 








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

RE: connection pooling

[Andrew Conrad]

Use a monitoring tool on your RDBMS.  For SQL Server I use "Profiler".


- Andrew

> -Original Message-
> From: Pop Marius [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, July 25, 2002 5:00 AM
> To: tomcat
> Subject: connection pooling
> 
> 
> 
> Hi everybody !
> 
> I'm using Tomcat 4 and my application works. To get a 
> connection to database I have the following code:
> 
>   Context initCtx = new InitialContext();
>   Context envCtx = (Context) initCtx.lookup("java:comp/env");
> 
>   DataSource ds = (DataSource)envCtx.lookup("jdbc/orgDB");
>   return  ds.getConnection();
> 
> and of course in the server.xml the necessary resource 
> requirements ! The application works fine, but How could I 
> ensure myself that the connections provided are reused, that 
> the pooling machine works, and I really have a pooling mechanism.
> 
> How can I test it ! The documentation sais that 
> ds.getConnection() gets a connection from the pool (which 
> pool, how) but I'm not sure that !
> 
> Any idea would be helpful !
> 
> 
> 
> 
> Pop Marius Lucian
> 

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

can not build libjkjni.so

[Dev Zero G Ltd]

We are trying to get the mod_jk working on FreeBSD 4.4, tomcat 4.0.4, 
apache 2.0.39, jdk 1.4.0

We have so far successfully built mod_jk2.so and all the jars, but now 
are having problems with libjkjni.so

Can somebody help, PLEASE?!! WE ARE SO CLOSE...

 what we've done 

updated from cvs jakarta-tomcat-connectors (~15:00 GMT+00)

${conn_root}/utils: cp build.properties.sample build.properties
ant
${conn_root}/jk: cp build.properties.sample build.properties

in build.properties:
set catalina.home
set tomcat4.home to catalina.home
set apache.home

${conn_root}/coyote
cp build.properties.sample build.properties
ant

${conn_root}/
ant

${conn_root}/
cp jtc.jar ${catalina.home}/server/lib
cp ${jtc.home}/jk/build/lib/tomcat-jni.jar ${catalina.home}/bin
cd ${catalina.home}/server/lib
rm tomcat-ajp.jar tomcat-util.jar tomcat-coyote.jar tomcat-http11.jar
cd ${catalina.home}
vi conf/server.xml

add coyote connector:



${conn_root}/jk
chmod -r +x *.sh
./buildconf.sh
vi configure

//  find key --no-verify and remove it - in other way following 
configure run fails with message "--no-verify requires host" or 
something else

./configure --with-apxs=/usr/local/apache2/bin/apxs 
--with-java-home=${JAVA_HOME} --with-java-platform=2 -enable-jni
// in common, apache2 and jni folders need to edit Makefile because (my 
shell is csh)
// a)  libtool must be defined as "libtool" but not "/bin/csh libtool"
b) in some places in Makefile's statement $< I've replaced by
certain file name ( .la). I don't know why it doesn't work (we're new to 
unix C programming)

make
make install
${conn_root}/jk/apache2
cp mod_jk.so /usr/local/apache2/modules

 QUESTION -
Where can we find .so library to place into ${catalina.home}/lib folder? 
It must be libjkjni.so, or something like that, right?

We are mainly folowing instructions from 
http://www.pubbitch.org/jboss/mod_jk2.html
and from http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/ajp.html

Any more advice, pointers, ideas, suggestions - will be greatful for 
_anything_

Thanks in advance!!


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

Re: connection pooling

[Craig R. McClanahan]

On Thu, 25 Jul 2002, Pop Marius wrote:

> Date: Thu, 25 Jul 2002 11:00:05 +0200
> From: Pop Marius <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: tomcat <[EMAIL PROTECTED]>
> Subject: connection pooling
>
>
> Hi everybody !
>
> I'm using Tomcat 4 and my application works. To get a connection to database I have 
>the following code:
>
>   Context initCtx = new InitialContext();
>   Context envCtx = (Context) initCtx.lookup("java:comp/env");
>
>   DataSource ds = (DataSource)envCtx.lookup("jdbc/orgDB");
>   return  ds.getConnection();
>
> and of course in the server.xml the necessary resource requirements !
> The application works fine, but How could I ensure myself that the
> connections provided are reused, that the pooling machine works, and I
> really have a pooling mechanism.
>
> How can I test it ! The documentation sais that ds.getConnection() gets
> a connection from the pool (which pool, how) but I'm not sure that !
>

It gets a connection from the pool that you configured with your resource
settings in server.xml.

> Any idea would be helpful !
>

The normal pattern for using a connection from a data source like this
(including your code from above):

  Context initCtx = new InitialContext();
  Context envCtx = (Context) initCtx.lookup("java:comp/env");
  DataSource ds = (DataSource) envCtx.lookup("jdbc/orgDB");
  Connection conn= ds.getConnextion();
  ... use the connection to do your database access ...
  conn.close();

The last call doesn't actually close the underlying database connection --
it just returns this instance to the connection pool.

>
>
>
> Pop Marius Lucian
>

Craig



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

Re: JSR77 & tomcat5 configuration

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> It seems JSR77 has been posted - I think everyone should read it.
> 
> What's important is the set of naming conventions for the managed
> objects we expose - I strongly believe that we should use those
> names wherever we provide the equivalent functionality.
> 
> For example ( on what is important for me ): 
> - 'node' attribute - instead of jvmRoute 
> - each tomcat instance in a distributed config must know 
> about all other
> - we should start exposing mbeans for JVM, WebModule and 
> servlets using the naming conventions.
> 
> Of course, we should keep backward compat - but all old
> attribute names should be eventually deprecated.
> 
> As I mentioned in the past, I'm not happy with XmlMapper/Digester
> style used for configuration and I'm not happy with either 
> server.xml format or with the way we save the config.
> 
> At this moment I have a very strong belief ( and it's getting 
> stronger every day ) that we should adopt a configuration 
> close to the JMX model, where every configurable object
> is a named mbean. 
> 
> That means no more Interceptor/Context/Server/Valve/Listener/etc.
> 
> I also thing the configuration should be centered around a
> class similar with RuntimeConfigurable on ant, where all the
>  user settings are stored ( including ${props} ). Any 
> configuration action that involves persistence should operate
> on the RuntimeConfigurable, which should deal with saving
> the config ( in a form as close as possible to the original 
> user configuration ).
> 
> While I think XmlMapper/Digester are very powerfull tools, I think
> tomcat5 should follow a model that is closer to ant - i.e. 
> a set of patterns and a flatter configuration file. This has proven
> to be easy and is well-understood ( even if I wrote a lot of 
> code in xmlMapper, I do have troubles sometimes with it, and
> nobody can claim it's as easy as ant tasks).
> 
> The question is: What do you think :-) ? 

Maybe it's time to plan for a change ...

This points out at the need for a new JSR 77 aware servlet container 
(which would likely reuse lots of code from the current Catalina). It's 
a good thing the core is now separate from the servlet container ;-)

Remy


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

DO NOT REPLY [Bug 11165] - Install task assumes the war file is readable

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

Install task assumes the war file is readable

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 12:30 ---
Use deploy (it uploads the WAR).

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

DO NOT REPLY [Bug 11165] New: - Install task assumes the war file is readable

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

Install task assumes the war file is readable

   Summary: Install task assumes the war file is readable
   Product: Tomcat 4
   Version: 4.1.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The scenario is as follows: 

1. Tomcat is started as root as some other kind of special user 
   (tomcat maybe) 
2. I do my development as my self. When I try to install a war file it  
   complains about: 
   2002-07-25 13:50:47 StandardContext[/nowise]: Error initializing
   resources: Doc base must point to a WAR file

The problem here is that the Tomcat server tries to read the war file 
itself. The Tomcat server falsly assumes that it has read access to the 
path it got. But in my case it doesn't. 

I don't know if this is possible, but a better solution would be to 
transfer the war file to the server as my user.

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

cvs commit: jakarta-tomcat-catalina/etc mx4j.license

[remm]

remm2002/07/25 05:01:22

  Modified:.build.xml
   catalina build.xml
   catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
  Added:   etc  mx4j.license
  Removed: catalina/src/share/org/apache/catalina/startup
CatalinaManager.java CatalinaManagerMBean.java
EmbeddedManager.java EmbeddedManagerMBean.java
  Log:
  - Fix a few basic problems with the scripts.
  
  Revision  ChangesPath
  1.2   +5 -11 jakarta-tomcat-catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 18 Jul 2002 16:47:24 -  1.1
  +++ build.xml 25 Jul 2002 12:01:22 -  1.2
  @@ -5,21 +5,15 @@
   
 
 
  -  
  -  
  +  
   
 
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -
  +  
   
 
  +  
 
   
  
  
  
  1.2   +7 -7  jakarta-tomcat-catalina/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 18 Jul 2002 16:47:30 -  1.1
  +++ build.xml 25 Jul 2002 12:01:22 -  1.2
  @@ -5,15 +5,14 @@
   
 
 
  -  
  +  
   
 
  -  
  -  
  -  
  -  
  +  
  +  
  +  
 
 
 
  @@ -28,6 +27,7 @@
   
 
 
  +  
 
 
 
   
  -
  +
 
 
   
  
  
  
  1.2   +5 -53 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
  
  Index: MBeanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- MBeanUtils.java   18 Jul 2002 16:48:00 -  1.1
  +++ MBeanUtils.java   25 Jul 2002 12:01:22 -  1.2
  @@ -98,7 +98,6 @@
   import org.apache.catalina.User;
   import org.apache.catalina.UserDatabase;
   import org.apache.catalina.Valve;
  -import org.apache.catalina.connector.http.HttpConnector;
   import org.apache.catalina.core.StandardService;
   import org.apache.catalina.deploy.ContextEnvironment;
   import org.apache.catalina.deploy.ContextResource;
  @@ -137,10 +136,6 @@
 "CoyoteConnector" },
   { "org.apache.catalina.core.StandardDefaultContext",
 "DefaultContext" },
  -{ "org.apache.catalina.connector.http10.HttpConnector",
  -  "Http10Connector" },
  -{ "org.apache.catalina.connector.http.HttpConnector",
  -  "Http11Connector" },
   { "org.apache.catalina.users.JDBCGroup",
 "Group" },
   { "org.apache.catalina.users.JDBCRole",
  @@ -808,50 +803,7 @@
   throws MalformedObjectNameException {
   
   ObjectName name = null;
  -if (connector instanceof HttpConnector) {
  -HttpConnector httpConnector = (HttpConnector) connector;
  -Service service = httpConnector.getService();
  -String serviceName = null;
  -if (service != null)
  -serviceName = service.getName();
  -name = new ObjectName(domain + ":type=Connector" +
  -  ",service=" + serviceName +
  -  ",port=" + httpConnector.getPort() +
  -  ",address=" + httpConnector.getAddress());
  -return (name);
  -} else if (connector instanceof 
org.apache.catalina.connector.http10.HttpConnector) {
  -org.apache.catalina.connector.http10.HttpConnector httpConnector =
  -(org.apache.catalina.connector.http10.HttpConnector) connector;
  -Service service = httpConnector.getService();
  -String serviceName = null;
  -if (service != null)
  -serviceName = service.getName();
  -name = new ObjectName(domain + ":type=Connector" +
  -  ",service=" + serviceName+
  -  ",port=" + httpConnector.getPort() +
  -  ",address=" + httpConnector.getAddress());
  -return (name);
  -} else if ("org.apache.ajp.tomcat4.Ajp13Connector".equals
  -   (connector.getClass().getName())) {
  -try {
  -String address = (String)
  -PropertyUtils.getSimpleProperty(connector, "address");
  -Integer port = (Integer)
  -PropertyUtils.getSimpleProperty(connector, "port");
  -Service service = con

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

[remm]

remm2002/07/25 05:01:05

  Modified:.build.xml
  Added:   .build.properties.default
  Removed: .build.properties.sample
  Log:
  - Fix a few basic problems with the scripts.
  
  Revision  ChangesPath
  1.2   +23 -9 jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 19 Jul 2002 00:39:13 -  1.1
  +++ build.xml 25 Jul 2002 12:01:05 -  1.2
  @@ -8,6 +8,7 @@
 
 
 
  +  
   
 
 
  @@ -20,6 +21,16 @@
 
 
   
  +  
  +  
  +  
  +  
  +  
  +
 
 
 
  @@ -32,19 +43,16 @@
 
   
   
  -  
  -  
  -  
  -  
  -
  -
 
 
   
  +
  +
  +
  +
  +
  +
   
   
   
  @@ -64,6 +72,8 @@
 
 
  +Target: API - Dist ...
  +
   Target: Catalina - Deploy ...
   
   Target: Jasper - Deploy ...
  @@ -77,6 +87,8 @@
 
   
  +Target: API - Clean ...
  +
   Target: Catalina - Clean ...
   
   Target: Jasper - Clean ...
  @@ -90,6 +102,8 @@
 
 
  +Target: API - Dist ...
  +
   Target: Catalina - All ...
   
   Target: Jasper - All ...
  
  
  
  1.1  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  # -
  # build.properties.sample
  #
  # This is an example "build.properties" file, used to customize building Tomcat
  # for your local environment.  It defines the location of all external
  # modules that Tomcat depends on.  Copy this file to "build.properties"
  # in the top-level source directory, and customize it as needed.
  #
  # $Id: build.properties.default,v 1.1 2002/07/25 12:01:05 remm Exp $
  # -
  
  
  # - Compile Control Flags -
  compile.debug=on
  compile.deprecation=off
  compile.optimize=on
  
  
  # - Build Control Flags
  
  #Build all components
  #full.dist=on
  
  #Build lightweight JDK 1.4 distribution
  #light.dist=on
  
  #Hide configuration flags display
  #flags.hide=on
  
  #Version number
  version=5.0
  
  # - CVS setup
  #Proxy to download subproject
  #proxy.host=proxy.domain
  #proxy.port=8080
  #proxy.use=on
  
  #CVS root for the jakarta repositories.
  cvsroot=":pserver:[EMAIL PROTECTED]:/home/cvspublic"
  
  
  # - Default Base Path for Dependent Packages -
  base.path=/usr/local
  
  
  # --
  #REQUIRED LIBRARIES
  # --
  
  
  # - Commons Beanutils, version 1.1 or later -
  commons-beanutils.home=${base.path}/commons-beanutils-1.3
  commons-beanutils.lib=${commons-beanutils.home}
  commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
  
commons-beanutils.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.3/commons-beanutils-1.3.tar.gz
  
  
  # - Commons Collections, version 1.0 or later -
  commons-collections.home=${base.path}/commons-collections-2.0
  commons-collections.lib=${commons-collections.home}
  commons-collections.jar=${commons-collections.lib}/commons-collections.jar
  
commons-collections.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.0/commons-collections-2.0.tar.gz
  
  
  # - Commons Digester, version 1.1.1 or later -
  commons-digester.home=${base.path}/commons-digester-1.2
  commons-digester.lib=${commons-digester.home}
  commons-digester.jar=${commons-digester.lib}/commons-digester.jar
  
commons-digester.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.2/commons-digester-1.2.tar.gz
  
  
  # - Commons Logging, version 1.0.1 or later -
  commons-logging.home=${base.path}/commons-logging-1.0.1
  commons-logging.lib=${commons-logging.home}
  commons-logging-api.jar=${commons-logging.lib}/commons-logging-api.jar
  commons-logging.jar=${commons-logging.lib}/commons-logging.jar
  commons-logging.loc=jakarta-commons/logging
  
#commons-logging.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.1/commons-logging-1.0.1.tar.gz
  
  
  # - Java Naming and Directory Interface (JNDI), version 1.2 or later -
  # Note: Optional with JDK 1.3+
  jndi.home=${base.path}/jndi-1.2.1
  jndi.lib=${jndi.home}/lib
  jndi.jar=${jndi.lib}/jndi.jar
  ldap.jar=${jndi.lib}/ldap.jar
  jaas.jar=${jndi.lib}/jaas.jar
  
  
  # - Jakarta Regular Expressions Library, version 1.2 -
  regexp.home=${base.path}/jakarta-regexp-1.2
  regexp.lib=${regexp.home}
  regexp.jar=${regexp.lib}/jakarta-re

Re: bug #11043

[peter lin]

Can any body give me a tip on where to look within catalina to patch the
bug I submitted?  It's not critical, but it's also not trivial, since
I'm not the only one who wants to use ServletContextListener to start up
an application.  If anyone is willing to give me a tip as to where to
look, I want to fix it this weekend and submit a patch so that it can be
included in 4.1.x release.

I've verified it exists in 4.0.3, 4.0.4 and 4.1.8. A paraphrase of the
bug is when the root directory is set to something other than "ROOT", it
creates two instance of the ServletContextListener listed in web.xml and
fires the event twice.


peter lin
 

peter lin wrote:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11043
> 
> hey remmy,
> 
> I was thinking of debugging the bug I reported earlier this week.  Can
> you give me any tips as to where to look, so that I can fix it and
> submit a patch for it this weekend?
> 
> thanks
> 
> peter lin
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: [logging] Redirecting System.out to JDK1.4 Logging for tomcat

[Bob Herrmann]

On Thu, 2002-07-25 at 07:13, Remy Maucherat wrote:
> Bob Herrmann wrote:
> > I don't know if anyone else will find this interesting, but I wrote a
> > class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
> > aware and unrolls the stack in a way useful for Tomcat.  This might be
> > useful if you are embedding Tomcat.
> > 
> > I changed catalina.sh to start my class, it then invokes Bootstrap.
> > 
> > Any comments?
> 
> AFAIK, Glenn used the Jasper sys.out redirector (and put it in 
> j-t-c/util) to do that. It doesn't redirect everything, but I believe it 
> redirects everything significant.
> 
> The advantages are:
> - It then redirects to one of the Catalina loggers
> - It doesn't depend on JDK 1.4

True.  My approach is tuned for 2 things,
 - utilizing JDK 1.4 logging 
 - unrolling the Tomcat stack in a way to get to "interesting bits of
stack"

You are right that this isn't something everyone would want.  If you are
trying to get Tomcat to log though JDK 1.4, then my approach might be
useful.  

The stack unrolling is helpful, IMHO, because it helps to identify which
class and method called the logger.  

I would like to have used commons-logging to get to JDK1.4's backend. 
Alas commons-logging doesn't support arbitrary stack unrolling
methods... And Tomcat has a lot of log wrappers

$ cd jakarta-tomcat-4.0
$ grep -i 'log(' `find . -name *.java `|grep void|cut -f1
-d:|sort|uniq|wc -l
 65

To migrate to commons-logging, it looks like at least 65 classes need to
be adjusted.  I presume this will take awhile.  Using my approach is a
quick stop gap.   Perhaps Tomcat 5 will embrace the migration to
commons-logging.

Cheers,
-bob

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



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



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

Re: [logging] Redirecting System.out to JDK1.4 Logging for tomcat

[Remy Maucherat]

Bob Herrmann wrote:
> I don't know if anyone else will find this interesting, but I wrote a
> class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
> aware and unrolls the stack in a way useful for Tomcat.  This might be
> useful if you are embedding Tomcat.
> 
> I changed catalina.sh to start my class, it then invokes Bootstrap.
> 
> Any comments?

AFAIK, Glenn used the Jasper sys.out redirector (and put it in 
j-t-c/util) to do that. It doesn't redirect everything, but I believe it 
redirects everything significant.

The advantages are:
- It then redirects to one of the Catalina loggers
- It doesn't depend on JDK 1.4

Remy


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

DO NOT REPLY [Bug 5709] - HttpServletRequest.getHost returns web server address or null, not client address

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

HttpServletRequest.getHost returns web server address or null, not client address





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:10 ---
tomcat 3 has code in HttpServletRequestFacade.getRemoteHost() that tests whether
the remoteHost has already been set or not. The patch simply puts this code into
tomcat4, but now it's in RequestFacade.getRemoteHost()

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

DO NOT REPLY [Bug 5709] - HttpServletRequest.getHost returns web server address or null, not client address

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

HttpServletRequest.getHost returns web server address or null, not client address





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:06 ---
Created an attachment (id=2485)
Patch, restores behavior of tomcat 3

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

DO NOT REPLY [Bug 7602] - After RequestDispatcher.forward() the character encoding for parameters is set to ISO-8859-1

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

After RequestDispatcher.forward() the character encoding for parameters is set to 
ISO-8859-1





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:02 ---
Why use a default of "ISO-8859-1" or "UTF-8" ? Why don't use the page encoding 
defined by, e.g. <%@ page contentType="text/html; charset=Big5"%> on the page 
head ?

People always use same encoding across the whole application, even for 
internationisation they will choose whatever suitable encoding and fixed to use 
it across whole application.

As we, the Multi-byte character user, need to explicitly call 

request.setCharacterEncoding("BIG5");

before getting the passed in Chinese parameters for processing, or-else the 
parameters are decoded using "ISO-8859-1" uselessly.

Also, I suggest to add / change the code of method to facilitate for re-doing 
the parameter parsing using another encoding for the rare case that different 
encodings are required to use across application.

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

[logging] Redirecting System.out to JDK1.4 Logging for tomcat

[Bob Herrmann]

I don't know if anyone else will find this interesting, but I wrote a
class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
aware and unrolls the stack in a way useful for Tomcat.  This might be
useful if you are embedding Tomcat.

I changed catalina.sh to start my class, it then invokes Bootstrap.

Any comments?

Cheers,
-bob







? patch.txt
? catalina/src/share/org/apache/catalina/startup/Tomcat2Jdk14Log.java
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -r1.124 build.xml
1073a1074
> 
Index: catalina/src/bin/catalina.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.31
diff -r1.31 catalina.sh
209c209
<   org.apache.catalina.startup.Bootstrap "$@" start \
---
>   org.apache.catalina.startup.Tomcat2Jdk14Log "$@" start \




package org.apache.catalina.startup;

import java.io.OutputStream;
import java.io.IOException;
import java.io.PrintStream;

import java.util.logging.Level;
import java.util.logging.Logger;

/* This class takes StandardOut and redirects it to the Jdk1.4 Logger.
 * It attempts to walk the stack in a way that is meaningful for Tomcat
 */

public class Tomcat2Jdk14Log extends OutputStream {

public static void main(String args[]) {
	PrintStream ps = ( new PrintStream( new Tomcat2Jdk14Log("SysOut", Level.INFO ) ) ); 
	System.setOut( ps );

	ps = (new PrintStream( new Tomcat2Jdk14Log("SysErr", Level.WARNING ) ) );
	// Humm... this causes an exception to start to be printed..
	//perhaps a re-entrant issue?
	//System.setErr(ps);

	// just passing through
	Bootstrap.main(args);
}

private StringBuffer sb = new StringBuffer();
private Level level;
private Logger jlog;

// some platforms use 1 char for newline, others use 2
private int preNewlineChar = -1;
private int newlineChar;

private Tomcat2Jdk14Log( String logName, Level level ){
	this.level = level;
	jlog = Logger.getLogger(logName);

String newline = System.getProperty( "line.separator" );
if ( newline.length() == 2 ) {
preNewlineChar = newline.charAt(0);
newlineChar = newline.charAt(1);
} else {
newlineChar = newline.charAt(0);
}
}


// should this be syncronized?
public void write(int x) throws java.io.IOException {
if ( x != newlineChar ) {
sb.append( (char)x );
	return;
}

	// deal with Windows/Unix newline stuff
	if ( preNewlineChar != -1
	 && sb.length() > 1 
	 && sb.charAt( sb.length() -1 ) == preNewlineChar) {
	sb.deleteCharAt( sb.length() -1 );
	}

	// get stack trace.  This is quite slow.  If method/classnames
	// arent needed this should be turned off
	StackTraceElement locations[] = new Throwable().getStackTrace();

	String cname="unknown";
	String method="unknown";
	boolean foundLogger = false;
	String myClassName = this.getClass().getName();

	// Stratagy for finding an "Interesting" tomcat stackframe
	for (int i=3;i< locations.length;i++ ) {
	StackTraceElement caller=locations[i];

	cname=caller.getClassName();
	if ( !foundLogger ){
		// PHASE I: find the tomcat logger (we assume different platforms might
		// have different levels of stack... so we whirl through until we see
		// something we recognize. )
		if ( !cname.equals( "org.apache.tomcat.util.log.SystemLogHandler" ))
		continue;
		foundLogger = true;
		continue;
	}

	method=caller.getMethodName();
	// PHASE II: get rid of wrappers on top of the wrapper
	if ( method.equals("log") || method.equals("internalLog") )
		continue;

	// add line # for fun.
	method += ":"+caller.getLineNumber();
	break;
	}

	jlog.logp( level, cname, method, sb.toString() );

	sb = new StringBuffer(200);
}


}



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

Re: mod_jk2.so compiled (after patching), but won't install

[Henri Gomez]

Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:

> > Which version of Apache 2.0 did you have ?
> 
> We are running Apache 2.0.39 on FreeBSD 4.4

good

> >>--- patch history start ---
> >>Filename: jk\native2\include\jk_mutex.h
> >>
> >>Line #:75
> >>Old line  :
> >>#ifdef HAS_APR
> >>New line:
> >>#if APR_HAS_THREADS
> > 
> > +1
> > 
> >>#ifdef HAS_APR
> > 
> > 
> >>Line #:121
> >>Old line  :
> >>#ifdef APR_HAS_THREADS
> >>
> >>New line:
> >>#if APR_HAS_THREADS
> >>
> >>Reason:This conditional define statement adjusts variable
> >>definition (threadMutex). Type of this variable depends on define
> >>directive conditions, but to have needed types there are some #ifdef
> >>statements on lines 75-81. So, those definition statements are not
> >>the same, and this situation causes build-time error, when compiler
> >>includes one header file (with one type defined inside), but variable
> >>tries to have another type (found by me in another .h file - not
> >>included while build time due to #ifdef directives). Such changes
> >>were done experimentally and may be not 100% correct. In original
> >>compiler fails with message like "syntax error on before
> >>apr_thread_mutex_t in line 121"
> >>
> > 
> > apr.h have #define APR_AS_THREADS 1 so both should be the same.
> > Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39
> ...
> > 
> 
> our version of apr.h has #define APR_HAS_THREADS 0

So you don't have THREADS and yes #ifdef APR_HAS_THREADS is invalid,
your patch is correct

> Maybe apache/connector has not been ported properly to FreeBSD?

Linux, solaris, windows and many stranges architectures (JF ;)
patches applied to jk_mutex.h

> >>Filename jk\native2\build.xml
> >>
> >>Line #:  374
> >>Action: commented
> >>
> >>Reason   :Having this link option uncommented (original) I could
> >>not acquire libjkjni.so, only .a and .la files present. As far as I
> >>am dummy in FreeBSD C/C++, I used something
> >>"try-to-change-something-and-see-what-you-get" method (it has pretty
> >>russian idiom,but I don't know its analog in English)
> >>
> >>Filename: jk\build.properties
> >>
> >>Some pathes set to correspond to reality (path to apache, etc)
> >>
> >>Filename:jk\native\apache-2.0\build-unix.sh
> >>
> >>Line #:  44
> >>Action:commented.
> >>Line #:  46
> >>Action:  uncommented and approved
> >>New line:
> >>INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
> > 
> > 
> > Don't use build-unix.sh but instead configure/make. The build.sh is no
> more
> > present in recent jtc cvs, deprecated in favor of autoconf/make 
> > 
> 
> will try this
> 
> > 
> >>Reason:while compiling mod_jk.so compiler could not see
> >>connectors includes. I added first statement to make it visible
> >>--- patch history end ---
> 
> Thanks again
> 
> 
> 




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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.am

[hgomez]

hgomez  2002/07/25 03:31:30

  Modified:jk/native/apache-1.3 Makefile.am
  Log:
  Make sure that apxs flags will be passed to libtool when building
  mod_jk.c (if not mod_jk.c will not be compiled with -DEAPI for example)
  
  Revision  ChangesPath
  1.7   +1 -1  jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.am
  
  Index: Makefile.am
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.am,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Makefile.am   5 Nov 2001 23:04:06 -   1.6
  +++ Makefile.am   25 Jul 2002 10:31:30 -  1.7
  @@ -16,7 +16,7 @@
   JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
  -AM_CFLAGS=@apache_include@ -I../common
  +AM_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I../common
   
   include ../common/list.mk.in
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_mutex.h

[hgomez]

hgomez  2002/07/25 03:02:21

  Modified:jk/native2/include jk_mutex.h
  Log:
  Correct preprocessor use of APR_HAS_THREADS, since APR
  make use of #define APR_HAS_THREADS 0 when no threads support
  (Reported by Dev Zero Ltd)
  
  Revision  ChangesPath
  1.4   +2 -2  jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h
  
  Index: jk_mutex.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_mutex.h6 Jun 2002 13:32:25 -   1.3
  +++ jk_mutex.h25 Jul 2002 10:02:21 -  1.4
  @@ -72,7 +72,7 @@
   struct jk_env;
   struct jk_mutex;
   
  -#ifdef HAS_APR
  +#if APR_HAS_THREADS
   #include "apr_thread_mutex.h"
   #elif defined( WIN32 )
   #include 
  @@ -118,7 +118,7 @@
   /* Private data */
   void *privateData;
   
  -#ifdef APR_HAS_THREADS
  +#if APR_HAS_THREADS
   apr_thread_mutex_t *threadMutex;
   #elif defined( WIN32 )
   CRITICAL_SECTION threadMutex;
  
  
  

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

Re: mod_jk2.so compiled (after patching), but won't install

[Dev Zero G Ltd]

Thanks very much for the help.

See below

Henri Gomez wrote:
> Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:
> 
>>First of all - many many thanks to everybody who has helped so far - we 
>>really appreciate it.. Just one last push required. :)
>>
>>We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
>>at the bottom of the mail), but can't install. We put them into 
>>$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
>>
>>But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
>>error message:
>>
>>--- error start ---
>>file://augada/usr/local/apache2/modules ../bin/apachectl configtest
>>Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
>>Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
>>/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
>>"apr_thread_mutex_trylock"
>>--- error end ---
>>
>>What could it be?
> 
> Which version of Apache 2.0 did you have ?

We are running Apache 2.0.39 on FreeBSD 4.4

> 
>>--- patch history start ---
>>Filename: jk\native2\include\jk_mutex.h
>>
>>Line #:75
>>Old line  :
>>#ifdef HAS_APR
>>New line:
>>#if APR_HAS_THREADS
> 
> +1
> 
>>#ifdef HAS_APR
> 
> 
>>Line #:121
>>Old line  :
>>#ifdef APR_HAS_THREADS
>>
>>New line:
>>#if APR_HAS_THREADS
>>
>>Reason:This conditional define statement adjusts variable
>>definition (threadMutex). Type of this variable depends on define
>>directive conditions, but to have needed types there are some #ifdef
>>statements on lines 75-81. So, those definition statements are not
>>the same, and this situation causes build-time error, when compiler
>>includes one header file (with one type defined inside), but variable
>>tries to have another type (found by me in another .h file - not
>>included while build time due to #ifdef directives). Such changes
>>were done experimentally and may be not 100% correct. In original
>>compiler fails with message like "syntax error on before
>>apr_thread_mutex_t in line 121"
>>
> 
> apr.h have #define APR_AS_THREADS 1 so both should be the same.
> Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...
> 

our version of apr.h has #define APR_HAS_THREADS 0

Maybe apache/connector has not been ported properly to FreeBSD?

> 
>>Filename jk\native2\build.xml
>>
>>Line #:  374
>>Action: commented
>>
>>Reason   :Having this link option uncommented (original) I could
>>not acquire libjkjni.so, only .a and .la files present. As far as I
>>am dummy in FreeBSD C/C++, I used something
>>"try-to-change-something-and-see-what-you-get" method (it has pretty
>>russian idiom,but I don't know its analog in English)
>>
>>Filename: jk\build.properties
>>
>>Some pathes set to correspond to reality (path to apache, etc)
>>
>>Filename:jk\native\apache-2.0\build-unix.sh
>>
>>Line #:  44
>>Action:commented.
>>Line #:  46
>>Action:  uncommented and approved
>>New line:
>>INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
> 
> 
> Don't use build-unix.sh but instead configure/make. The build.sh is no more
> present in recent jtc cvs, deprecated in favor of autoconf/make 
> 

will try this

> 
>>Reason:while compiling mod_jk.so compiler could not see
>>connectors includes. I added first statement to make it visible
>>--- patch history end ---

Thanks again


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

connection pooling

[Pop Marius]

Hi everybody !

I'm using Tomcat 4 and my application works. To get a connection to database I have 
the following code:

  Context initCtx = new InitialContext();
  Context envCtx = (Context) initCtx.lookup("java:comp/env");

  DataSource ds = (DataSource)envCtx.lookup("jdbc/orgDB");
  return  ds.getConnection();

and of course in the server.xml the necessary resource requirements !
The application works fine, but How could I ensure myself that the connections 
provided are reused,
that the pooling machine works, and I really have a pooling mechanism.

How can I test it ! The documentation sais that ds.getConnection() gets a connection 
from the pool (which pool, how) but I'm not sure that !

Any idea would be helpful !




Pop Marius Lucian

Re: mod_jk2.so compiled (after patching), but won't install

[Henri Gomez]

Quoting Dev Zero G Ltd <[EMAIL PROTECTED]>:

> First of all - many many thanks to everybody who has helped so far - we 
> really appreciate it.. Just one last push required. :)
> 
> We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
> at the bottom of the mail), but can't install. We put them into 
> $(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
> 
> But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
> error message:
> 
> --- error start ---
> file://augada/usr/local/apache2/modules ../bin/apachectl configtest
> Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
> Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
> /usr/local/apache2/modules/mod_jk2.so: Undefined symbol
> "apr_thread_mutex_trylock"
> --- error end ---
> 
> What could it be?

Which version of Apache 2.0 did you have ?


> --- patch history start ---
> Filename: jk\native2\include\jk_mutex.h
> 
> Line #:75
> Old line  :
> #ifdef HAS_APR
> New line:
> #if APR_HAS_THREADS

+1

> #ifdef HAS_APR


> Line #:121
> Old line  :
> #ifdef APR_HAS_THREADS
> 
> New line:
> #if APR_HAS_THREADS
> 
> Reason:This conditional define statement adjusts variable
> definition (threadMutex). Type of this variable depends on define
> directive conditions, but to have needed types there are some #ifdef
> statements on lines 75-81. So, those definition statements are not
> the same, and this situation causes build-time error, when compiler
> includes one header file (with one type defined inside), but variable
> tries to have another type (found by me in another .h file - not
> included while build time due to #ifdef directives). Such changes
> were done experimentally and may be not 100% correct. In original
> compiler fails with message like "syntax error on before
> apr_thread_mutex_t in line 121"
>
apr.h have #define APR_AS_THREADS 1 so both should be the same.
Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...

> Filename jk\native2\build.xml
> 
> Line #:  374
> Action: commented
> 
> Reason   :Having this link option uncommented (original) I could
> not acquire libjkjni.so, only .a and .la files present. As far as I
> am dummy in FreeBSD C/C++, I used something
> "try-to-change-something-and-see-what-you-get" method (it has pretty
> russian idiom,but I don't know its analog in English)
> 
> Filename: jk\build.properties
> 
> Some pathes set to correspond to reality (path to apache, etc)
> 
> Filename:jk\native\apache-2.0\build-unix.sh
> 
> Line #:  44
> Action:commented.
> Line #:  46
> Action:  uncommented and approved
> New line:
> INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"

Don't use build-unix.sh but instead configure/make. The build.sh is no more
present in recent jtc cvs, deprecated in favor of autoconf/make 

> Reason:while compiling mod_jk.so compiler could not see
> connectors includes. I added first statement to make it visible
> --- patch history end ---
> 
> 
> 
> 
> 




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

DO NOT REPLY [Bug 6832] - Locale of the browser is ignored by the AJP13 connector

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

Locale of the browser is ignored by the AJP13 connector





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 08:47 ---
zmiana z ajp13 na mod_jk2

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

DO NOT REPLY [Bug 4212] - How to configure Apache to serve static contents?

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

How to configure Apache to serve static contents?





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 08:38 ---
I don't think this is really a bug, It's a matter of configuration. Try the 
following: add these two lines at the end of your Apache httpd.conf file:

WebAppConnection warpConnection warp localhost:8008
WebAppDeploy myapp warpConnection /myapp/

where localhost is the name of the server under which you are running your 
webapp and myapp is the name of your webapp.

Now all requests to //localhost/myapp/ will be passed to Tomcat, while all 
other requests (like //localhost/img/ or //localhost/css/) will be dispatched 
by Apache.

I have this configuration running on my laptop and it works perfectly.

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

mod_jk2.so compiled (after patching), but won't install

[Dev Zero G Ltd]

First of all - many many thanks to everybody who has helped so far - we 
really appreciate it.. Just one last push required. :)

We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
at the bottom of the mail), but can't install. We put them into 
$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.

But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
error message:

--- error start ---
file://augada/usr/local/apache2/modules ../bin/apachectl configtest
Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
"apr_thread_mutex_trylock"
--- error end ---

What could it be?

--- patch history start ---
Filename: jk\native2\include\jk_mutex.h

Line #:75
Old line  :
#ifdef HAS_APR
New line:
#if APR_HAS_THREADS

Line #:121
Old line  :
#ifdef APR_HAS_THREADS

New line:
#if APR_HAS_THREADS

Reason:This conditional define statement adjusts variable
definition (threadMutex). Type of this variable depends on define
directive conditions, but to have needed types there are some #ifdef
statements on lines 75-81. So, those definition statements are not
the same, and this situation causes build-time error, when compiler
includes one header file (with one type defined inside), but variable
tries to have another type (found by me in another .h file - not
included while build time due to #ifdef directives). Such changes
were done experimentally and may be not 100% correct. In original
compiler fails with message like "syntax error on before
apr_thread_mutex_t in line 121"

Filename jk\native2\build.xml

Line #:  374
Action: commented

Reason   :Having this link option uncommented (original) I could
not acquire libjkjni.so, only .a and .la files present. As far as I
am dummy in FreeBSD C/C++, I used something
"try-to-change-something-and-see-what-you-get" method (it has pretty
russian idiom,but I don't know its analog in English)

Filename: jk\build.properties

Some pathes set to correspond to reality (path to apache, etc)

Filename:jk\native\apache-2.0\build-unix.sh

Line #:  44
Action:commented.
Line #:  46
Action:  uncommented and approved
New line:
INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"

Reason:while compiling mod_jk.so compiler could not see
connectors includes. I added first statement to make it visible
--- patch history end ---




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