cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core mbeans-descriptors.xml

[billbarker]

billbarker2004/07/26 23:51:15

  Modified:catalina/src/share/org/apache/catalina/core
mbeans-descriptors.xml
  Log:
  Update the StandardContext MBean to match StandardContext.
  
  -- Adding antiResourceLocking attribute
  -- Remove the dynamic resource methods that are no longer in StandardContext.
  
  Revision  ChangesPath
  1.31  +13 -48
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml
  
  Index: mbeans-descriptors.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- mbeans-descriptors.xml14 Jul 2004 06:19:31 -  1.30
  +++ mbeans-descriptors.xml27 Jul 2004 06:51:14 -  1.31
  @@ -11,7 +11,7 @@
  description="Allow symlinking to outside the webapp root directory, 
if the webapp is an exploded directory"
  is="true"
  type="boolean"/>
  -  
  +
   
  @@ -67,6 +67,9 @@
 
  +  
   
   
   
  +  
   
   
   
 
  +
  +
   
  @@ -177,11 +187,6 @@
  description="Name of the engine domain, if different from the 
context domain"
  type="java.lang.String"/>
   
  -
  -
   
  +   type="org.apache.commons.logging.Log" />
 
   
   
  -
  -
   
 
  -
  -  
  -
  -
  -
  -  
  -
  -
  +
   
  -
  -
  -
  -  
  -
  -
  -
  -  
   
   
   

Re: Mod_ajp initial

[Ari Suutari]

Hi,

> I think we do have agreement on droping IIS/iPlanet.

Does this mean that in the future there won't be a way to
integrate tomcat to IIS ? We have some customers that
require use of IIS as frontend (for either political reasons or
they want to use integrated windows authentication feature of IIS).

Of course there are commercial products for this, but tomcat has just
been a very good companion to IIS in our systems. So I hope that
someone maintains some kind of solution for IIS integration.

Ari S.
--
Ari Suutari, Syncron Tech Oy, Finland



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

Gaston Lanteigne/CA/TA.NA is out of the office.

[Gaston Lanteigne]

I will be out of the office starting  07/16/2004 and will not return until
08/09/2004.

I will respond to your message when I return.


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

Re: Mod_ajp initial

[Costin Manolache]

Mladen Turk wrote:

Well, the way I see (think that Henri has the similar ideas) is to have the
ajp protocol lib, usable to communicate to TC from any container, not only
http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0
branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1
branch.
I agree with libajp.so.
I don't agree we need to develop new connector for apache2.0. If we 
can't get it backported to 2.0 - then we can just provide a separate 
build ( mod_proxy21 ).


So from the start we know what the final goal is, and what the life cycle of
it would be. The code itself (at least the ajp protocol library) will not be
a waste, cause we'll use it for both proxy_ajp and any later bizarre usage.
To effectively test the new ajp code we need some framework, simple enough
and Apache2 centric. We could use the current mod_proxy for that, but it's
current design need some changes to be able to support that, and BTW I'm
working on that together with Graham, but even he can not say for sure it's
going to be in 2.0 branch.

There is also a question of development infrastructure, cause we cannot use
the httpd-cvs for that, so we'll need to make some compromises, writing few
lines of code twice, and hope that somone will apply the patch :). 

We can very well put a copy of mod_proxy in our cvs while it is 
experimental - and give Graham access. The module can be 
tested/developed with both apache20 and 21.

I don't think infrastructure is the biggest problem. We are all on apache.

My concern is that we are just repeating the history of the first 4 
connectors - by writting some initial code that solves the 
easy problem 
( sending requests to tomcat ), and hoping the rest can be 
added without 
getting back to spaghetti.


Well, the only thing you can not beat is the time. It (the time) has a
strange side effect to make the things older. I clearly remember a day when
I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering
who will ever need that and for what.
My point was that repeating a mistake 4 times should be enough, we don't 
need a 5th repetition of the same history.

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

DO NOT REPLY [Bug 30340] New: - substract() disfunctional in CharChunk and ByteChunk classes

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30340

substract() disfunctional in CharChunk and ByteChunk classes

   Summary: substract() disfunctional in CharChunk and ByteChunk
classes
   Product: Tomcat 5
   Version: 5.0.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If a jsp or a servlet uses char read() on its JspReader, the call is eventually
passed to CharChunk (or ByteChunk) substract() method. The method body needs
fixing to be functional, see:
public int substract()
throws IOException {

if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadChars(buff, 0, buff.length);
if (n < 0)
return -1;
}

return (buff[start++]);

}

Should set end=start=0 after reading chars from in. The same for ByteChunk.

The next method, substract(CharChunk) does it... more or less.

Actually, I'd love to straighten up this code a little bit - but it would be
better to exchange opinions with the current author, Remy, regarding certain
methods and functionality, before doing anything.

Thanks,
Vlad Patryshev
[EMAIL PROTECTED]

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

RE: Dynamic updates and Apache v2.0

[Filip Hanik \(lists\)]

why are we so focused on dynamic this dynamic that, there is nothing about
mod_proxy that is dynamic, and instead of delaying the stability and release
of a working mod_proxy with a load balancer, make it work, make it work
well, then add fancy features. mod_jk2 became way to cluttered this exact
way, and never got to the point of workability to the point where any user
could configure it

just my $0.02
Filip

-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: Monday, July 26, 2004 11:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Dynamic updates and Apache v2.0


First, by "dynamic updates" I mean changes to apache2 config that don't
require a restart. For example, .htaccess files provide such a thing (
for a different area ).

What updates ? There are several forms:

1.
- add a new worker to a pool ( for example - expect big load, you buy
more hardware, etc ).

- gracefully remove a worker ( for upgrade for example ) - the
implication is that sticky sessions will still go, no new sessions.

- change parameters of a worker ( like balancing factors ). That may
include advanced balancing.

Note that for all this you don't actually need too much change on
apache/mod_proxy - as long as you treat the "pool" as one entity, and
maybe use a separate config file for the list of workers ( so you don't
have to regenerate httpd.conf - which is quite difficult ). There are
many ways to implement the communication between httpd processes and
between apache and tomcat.

2.
- add more webapps and virtual servers - for example in the case of an ISP.

- reload webapps - that means some mappings and auth changes, in the
case of tight integration you may want to have apache handle auth and
mapping



Costin


Graham Leggett wrote:

> Hi all,
>
> I am starting a new thread for this, as it seems to be an important
> killer-app feature for any httpd v2.0 integration.
>
> People have said the config should be dynamically configurable - which
> part of the config should be dynamically configurable?
>
> In other words, would any of these senarios make sense:
>
> - A potential pool of servers (IP address/port combinations) is defined,
> and httpd gracefully handles the case where a server is "missing".
> Adding a new server is as simple as starting it up on one of the
> predefined ip/ports combinations. An admin might configure an entire
> subnet as "tomcat servers", and then add and remove backend servers at
> will. Easy to do, but a bit limiting.
>
> - httpd is informed via a special URL of updates to the servers on the
> backend, a bit like the management app in tomcat. This functionality
> might grow to being available to the whole httpd config. Being a URL, it
> would be pretected by standard mechanisms like SSL and basic
> authentication. Powerful, but a big change that will likely only appear
> in httpd v2.1 or v2.2.
>
> - httpd polls the backend servers using the OPTIONS method (as was
> recommended recently). In the info returned, httpd learns of the
> intended weighting of the servers, whether a server needs to be removed
> gracefully from the pool, or whether other servers have been added to
> the pool and should be included in the config. Here httpd needs only to
> be told about just one backend server, which will "seed" httpd with info
> about all the other servers.
>
> Out of the above three the third option seems to make the most sense.
> It's not very obtrusive, it can be used with backends other than tomcat.
> Actually updating the server list and weightings can be done via the
> tomcat management app, which already exists now (as opposed to a
> theoritical management app for httpd).
>
> Thoughts?
>
> Regards,
> Graham
> --


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004


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

DO NOT REPLY [Bug 30332] - Field charsetSet reset problem in class org.apache.coyote.Response

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30332

Field charsetSet reset problem in class org.apache.coyote.Response





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 23:01 ---
A simple test case works for me and a check with telnet comfirms that the 
header is as expected.

Can you provide a simple test case, perferably as a ready to deploy war, that 
exhibits this behaviour?

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

DO NOT REPLY [Bug 12056] - Startup scripts test for invalid permissions.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=12056

Startup scripts test for invalid permissions.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 22:03 ---
Your proposed patch has been applied to CVS for TC4 (and TC5).

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

cvs commit: jakarta-tomcat-catalina/catalina/src/bin setclasspath.sh

[markt]

markt   2004/07/26 15:01:19

  Modified:catalina/src/bin setclasspath.sh
  Log:
  Fix bug 12056. Test for execute rather than read permissions since execute is what 
we need.
  Add missing JDK not JRE warning.
   - Ported from TC4
  
  Revision  ChangesPath
  1.8   +5 -4  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- setclasspath.sh   12 Feb 2004 21:38:56 -  1.7
  +++ setclasspath.sh   26 Jul 2004 22:01:19 -  1.8
  @@ -11,13 +11,14 @@
 exit 1
   fi
   if $os400; then
  -  if [ ! -r "$JAVA_HOME"/bin/java -o ! -r "$JAVA_HOME"/bin/javac ]; then
  +  if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
  +echo "NB: JAVA_HOME should point to a JDK not a JRE"
   exit 1
 fi
   else
  -  if [ ! -r "$JAVA_HOME"/bin/java -o ! -r "$JAVA_HOME"/bin/jdb -o ! -r 
"$JAVA_HOME"/bin/javac ]; then
  +  if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/jdb -o ! -x 
"$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
   echo "NB: JAVA_HOME should point to a JDK not a JRE"
  @@ -29,7 +30,7 @@
 echo "This environment variable is needed to run this program"
 exit 1
   fi
  -if [ ! -r "$BASEDIR"/bin/setclasspath.sh ]; then
  +if [ ! -x "$BASEDIR"/bin/setclasspath.sh ]; then
 echo "The BASEDIR environment variable is not defined correctly"
 echo "This environment variable is needed to run this program"
 exit 1
  
  
  

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

DO NOT REPLY [Bug 30332] New: - Field charsetSet reset problem in class org.apache.coyote.Response

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30332

Field charsetSet reset problem in class org.apache.coyote.Response

   Summary: Field charsetSet reset problem in class
org.apache.coyote.Response
   Product: Tomcat 4
   Version: 4.1.30
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are still having problems with response content-type to have ";charset=UTF-8"
automatically attached even though we explicitly called
HttpServletResponse.setContentType("application/pdf") and never called
setCharacterEncoding() in the same request. As a matter of fact, after putting
some debugging code in org.apache.coyote.Response.setCharacterEncoding(), I
found out it was never called in the request that we use to send the PDF file.
The debugging also showed that the member variable "charsetSet" was true before
setContentType() was called. Therefore, I suspect the recycle()/reset() method
in this class wasn't called when it needs to be called. On the other hand, does
it make sense to add "charsetSet = false;" at the beginning of the
setContentType() method?

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

DO NOT REPLY [Bug 30331] New: - META-INF/context.xml creates conf/.../foo.xml as a directory

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30331

META-INF/context.xml creates conf/.../foo.xml as a directory

   Summary: META-INF/context.xml creates conf/.../foo.xml as a
directory
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a WAR named "survey.war" with a META-INF/context.xml file declaring an
alternate security realm.  When I drop that WAR in tomcat/webapps, it creates
conf/Catalina/localhost/survey.xml/ as a directory.  The directory contains
nothing.  Then when redeploying, it complains that it's a directory not a file
and gives a stack trace.  Presumably, it should have just copied my context.xml
to a file at that location -- I'm not sure why it creates it as a directory.

EVERE: Error deploying configuration descriptor survey.xml
java.io.IOException: java.io.FileNotFoundException:
/server/tomcat-5.0.27/conf/Catalina/localhost/survey.xml (Is a directory)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:494)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:863)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:482)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:968)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at org.apache.catalina.core.StandardService.start(StandardService.java:480)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)

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

cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.sh

[markt]

markt   2004/07/26 14:29:42

  Modified:catalina/src/bin setclasspath.sh
  Log:
  Fix bug 12056. Test for execute rather than read permissions since execute is what 
we need.
  Add missing JDK not JRE warning.
  
  Revision  ChangesPath
  1.13  +5 -4  jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- setclasspath.sh   12 Feb 2004 21:38:12 -  1.12
  +++ setclasspath.sh   26 Jul 2004 21:29:42 -  1.13
  @@ -11,13 +11,14 @@
 exit 1
   fi
   if $os400; then
  -  if [ ! -r "$JAVA_HOME"/bin/java -o ! -r "$JAVA_HOME"/bin/javac ]; then
  +  if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
  +echo "NB: JAVA_HOME should point to a JDK not a JRE"
   exit 1
 fi
   else
  -  if [ ! -r "$JAVA_HOME"/bin/java -o ! -r "$JAVA_HOME"/bin/jdb -o ! -r 
"$JAVA_HOME"/bin/javac ]; then
  +  if [ ! -x "$JAVA_HOME"/bin/java -o ! -x "$JAVA_HOME"/bin/jdb -o ! -x 
"$JAVA_HOME"/bin/javac ]; then
   echo "The JAVA_HOME environment variable is not defined correctly"
   echo "This environment variable is needed to run this program"
   echo "NB: JAVA_HOME should point to a JDK not a JRE"
  @@ -29,7 +30,7 @@
 echo "This environment variable is needed to run this program"
 exit 1
   fi
  -if [ ! -r "$BASEDIR"/bin/setclasspath.sh ]; then
  +if [ ! -x "$BASEDIR"/bin/setclasspath.sh ]; then
 echo "The BASEDIR environment variable is not defined correctly"
 echo "This environment variable is needed to run this program"
 exit 1
  
  
  

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

DO NOT REPLY [Bug 30291] - Wrong smap in expressions and scriptlets

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30291

Wrong smap in expressions and scriptlets

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 20:54 ---
Fixed in CVS.  Thnaks for reporting.

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

DO NOT REPLY [Bug 30289] - Wrong SMAP mappings with body dependent tags

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30289

Wrong SMAP mappings with body dependent tags

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 20:53 ---
Fixed in CVS.  Thanks for reporting.

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

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

[kinman]

kinman  2004/07/26 13:50:36

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - Fix 30291: Smap for a tag should not include its body.
  - Fix 30289: Incorrect Smap for multiple line java expression.
  
  Revision  ChangesPath
  1.236 +8 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.235
  retrieving revision 1.236
  diff -u -r1.235 -r1.236
  --- Generator.java23 Jul 2004 22:45:38 -  1.235
  +++ Generator.java26 Jul 2004 20:50:35 -  1.236
  @@ -830,7 +830,9 @@
   
   public void visit(Node.Expression n) throws JasperException {
   n.setBeginJavaLine(out.getJavaLine());
  -out.printil("out.print(" + n.getText() + ");");
  +out.printin("out.print(");
  +out.printMultiLn(n.getText());
  +out.println(");");
   n.setEndJavaLine(out.getJavaLine());
   }
   
  @@ -2125,9 +2127,9 @@
   
   Class tagHandlerClass = handlerInfo.getTagHandlerClass();
   
  -n.setBeginJavaLine(out.getJavaLine());
   out.printin("//  ");
   out.println(n.getQName());
  +n.setBeginJavaLine(out.getJavaLine());
   
   // Declare AT_BEGIN scripting variables
   declareScriptingVars(n, VariableInfo.AT_BEGIN);
  @@ -2221,7 +2223,10 @@
   out.pushIndent();
   }
   }
  -};
  +// Map the Java lines that handles start of custom tags to the
  +// JSP line for this tag
  +n.setEndJavaLine(out.getJavaLine());
  +}
   
   private void generateCustomEnd(
   Node.CustomTag n,
  @@ -2327,8 +2332,6 @@
   syncScriptingVars(n, VariableInfo.AT_END);
   
   restoreScriptingVars(n, VariableInfo.AT_BEGIN);
  -
  -n.setEndJavaLine(out.getJavaLine());
   }
   
   private void generateCustomDoTag(
  
  
  

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

RE: Mod_ajp initial

[Mladen Turk]

 

Costin Manolache wrote:
> > AFICR you said that you will have something to share, and 
> I'd love to see
> > some other, perhaps better ideas.
> 
> No, I'm trying stuff on java side.
>

OK.
 
> And just like with code - I don't think we are missing 
> propositions or 
> ideas. What is missing is an agreement over what features we 
> are going 
> to support ( and more exactly - not support ), as well as a 
> clear plan 
> on how to support them without spaghetti.
> 
> I think we do have agreement on droping IIS/iPlanet. We had 
> agreement on 
> droping pluggable protocol

Apache2, ajp13, TCP/IP
With possible dynamic config in stage 2 and ajp14 protocol extension using
crypto and compression.

That's it. We said that couple of times.

> - but that's now back with the 
> discussion on 
> mod_proxy ( which also involves pluggable protocol ).
> 

True, the work on that has been initiated, but it has a fundamental
difference being included in core httpd distribution. Only that fact is a
sufficient reason to forget that 'no plugable protocol' agreement, thought,
and of course the fact that the proxy is deeply integrated into the core of
httpd, as well as our protocol will consequently.

> 
> Yes, we do have plenty of connectors, and most were written 
> very fast - 
>mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy.
> 
> Having a 6th codebase - especially in the context of the growing 
> agreement over mod_proxy as a long-term solution - is not 
> what is missing.
> 

Well, the way I see (think that Henri has the similar ideas) is to have the
ajp protocol lib, usable to communicate to TC from any container, not only
http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0
branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1
branch.
So from the start we know what the final goal is, and what the life cycle of
it would be. The code itself (at least the ajp protocol library) will not be
a waste, cause we'll use it for both proxy_ajp and any later bizarre usage.
To effectively test the new ajp code we need some framework, simple enough
and Apache2 centric. We could use the current mod_proxy for that, but it's
current design need some changes to be able to support that, and BTW I'm
working on that together with Graham, but even he can not say for sure it's
going to be in 2.0 branch.

There is also a question of development infrastructure, cause we cannot use
the httpd-cvs for that, so we'll need to make some compromises, writing few
lines of code twice, and hope that somone will apply the patch :). 

> My concern is that we are just repeating the history of the first 4 
> connectors - by writting some initial code that solves the 
> easy problem 
> ( sending requests to tomcat ), and hoping the rest can be 
> added without 
> getting back to spaghetti.
> 

Well, the only thing you can not beat is the time. It (the time) has a
strange side effect to make the things older. I clearly remember a day when
I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering
who will ever need that and for what.


MT.


smime.p7s
Description: S/MIME cryptographic signature

Re: Dynamic updates and Apache v2.0

[Graham Leggett]

Costin Manolache wrote:
1.
- add a new worker to a pool ( for example - expect big load, you buy 
more hardware, etc ).

- gracefully remove a worker ( for upgrade for example ) - the 
implication is that sticky sessions will still go, no new sessions.

- change parameters of a worker ( like balancing factors ). That may 
include advanced balancing.

Note that for all this you don't actually need too much change on 
apache/mod_proxy - as long as you treat the "pool" as one entity, and 
maybe use a separate config file for the list of workers ( so you don't 
have to regenerate httpd.conf - which is quite difficult ). There are 
many ways to implement the communication between httpd processes and 
between apache and tomcat.
Don't forget that in many cases Apache will be running on a machine 
entirely outside of your direct control - a good example would be a 
network appliance.

There are many options for httpd to connect to the backend, and for the 
backend to connect to httpd, but there are limitations imposed by the 
environment where httpd will be running. Reading a file on disk is one 
example (you mentioned .htaccess files) - changing the file on disk does 
not mean httpd is necessarily going to pick up the changes straight 
away, and this assumes the admin has disk access at all.

Whatever solution we start with needs to keep these limitations in mind.
2.
- add more webapps and virtual servers - for example in the case of an ISP.
- reload webapps - that means some mappings and auth changes, in the 
case of tight integration you may want to have apache handle auth and 
mapping
Adding virtual servers requires an httpd config reload, this moves into 
the territory of having an httpd management app along the lines of the 
tomcat management app. Not a bad idea in itself, but a big project for 
httpd.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Jeg er på ferie

[richard . nilsen]

I will be out of the office starting  23.07.2004 and will not return until
16.08.2004.

Jeg sjekker mail innimellom. Er det ting rundt drift send mail til
[EMAIL PROTECTED]
Ha en fortsatt fin dag.

Mvh Richard D. Nilsen
Orkla Media SSIT


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

Re: Mod_ajp initial

[Costin Manolache]

Remy Maucherat wrote:
jean-frederic clere wrote:
We have noted that mod_proxy + mod_proxy_http are slow compared with 
mod_jk.
I think that the next step should be to try to find "why" instead 
writting a new modules. May be a quick hacked mod_proxy_ajp to replace 
mod_proxy_http is the first step.

Note that I am a bit reluctant to start a new module because I already 
had lost  a lot of time in mod_webapp ;-(

A lot of people lost time on various connectors, so you're not alone ;) 
(the list includes me with my old HTTP connector in Tomcat 4.0)

Rémy
Mod_jk, mod_jk2, http connector in 3.3, few ajp connectors and jserv on 
the java side, etc - it seems I lost quite a bit of time on connectors :-)

I'm more worried about lost of important features and things we learned 
than lost of code or even time. Most of the time was well spent - to 
learn stuff and solve problems, maybe not with the best solution but the 
best we could at that point.

Costin


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

PATCH: mod_jk get_cookie jvmroute fix

[Sandy McArthur]

Attached is a patch that fixes the get_cookie in jk_lb_worker.c taken 
from the CVS today.

The current implementation will fail if there are two JSESSIONID 
cookies at different domain levels. My patch below checks a JSESSIONID 
value for a known jvmroute before it returns a session cookie.

The logic isn't perfect but it better than the current implementation 
IMO. It could be made "more correct" if it verified the found jvmroute 
was at the end of the cookie's value instead of simply doing a strstr() 
for it. One could also argue that this changes the behavior enough that 
the function should be renamed as it's no longer a generic get_cookie 
function.

That said, the current patch, altered for mod_jk 1.2.5, is currently in 
production for webmail.ufl.edu where it's getting 15+ requests a 
second.

Sandy McArthur


jk_lb_worker.c-check-jvmroute.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature

cvs commit: jakarta-tomcat-catalina/catalina/src/conf server-minimal.xml

[remm]

remm2004/07/26 12:35:00

  Modified:catalina/src/conf server-minimal.xml
  Log:
  - Update server minimal as well.
  
  Revision  ChangesPath
  1.5   +3 -12 jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml
  
  Index: server-minimal.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- server-minimal.xml23 Jun 2004 13:51:38 -  1.4
  +++ server-minimal.xml26 Jul 2004 19:34:59 -  1.5
  @@ -3,18 +3,9 @@
   
   
  -
  -
  -   
  -factory
  -org.apache.catalina.users.MemoryUserDatabaseFactory
  -  
  -  
  -pathname
  -conf/tomcat-users.xml
  -  
  -
  +   description="User database that can be updated and saved"
  +   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
  +  pathname="conf/tomcat-users.xml" />
 
   
 
  
  
  

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

Re: TC 5: Support for multiple Coyote JK-Pools

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK 
pool at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor 
not only once, but for every Coyote JK pool configured in 
server.xml. For the second pool I get an exception when starting 
tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down 
correctly, and one of the two JK pools doesn't listen any more, 
but the second JK pool still listens and TC does not shut down. 
Retrying shutdown does not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?



Yes: use JDK 1.5 JMX instead of this code.



Are we going to switch to JDK1.5 ???
I missed this one.


Actually, I posted that we could consider switching to JDK 1.5, yes 
(I do really like that JDK). The idea is that I'm tweaking the API, 
so I would use the new stuff when rewriting code. I don't think it'll 
happen in the end, since not many people seem to be in favor of it.
Here, I was mentioning that using JDK 1.5 would be a workaround (as 
the connector registration moves out of the JVM).


Well, I like JDK1.5 as well - but I think we should follow the same 
path of keeping the base functionality available on lower VMs, and 
restrict 1.5 to individual components.

Not sure what you mean with "connector registration moves out of jvm" 
tough, but it sounds interesting :-)

Bad sentence, it should be "moves to the JVM". I don't know if you tried 
it, but there's a management.properties file that has all the options 
you could dream of to configure JMX remote :) Then you get fancy graphs 
without having to configure anything in Tomcat 
(http://mc4j.sourceforge.net/15Features_large.gif and the more "classic" 
http://mc4j.sourceforge.net/ss5_large.gif).

So it's less code in Tomcat for something a lot more powerful = I like 
it (even if I have to remove all the "enum" variables from my code).
Yes, I know jdk1.5 has this - however I tought we want to support this 
for lower VMs as well, it's important enough. And the typical solution 
is to have a module that does this - it is in j-t-c for the simple 
reason that coyote is used with all tomcat versions ( 3.3, 4.x, 5.x ) - 
so it is easier to place it there.

IMO we should stop making a strong distinction between the different 
plugins - connector, authenticator, logger, mapper, etc. They are all 
plugins, and it makes perfect sense to have a plugin that adds a jmx 
feature that is present in jdk1.5 and makes it available in jdk1.3 - 
that means easier transition to 1.5, consistent behavior, etc.

BTW - I preffer the http/servlet-based jmx console, as in mx4j or jboss.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
billbarker2004/07/26 10:04:04
 Modified:webapps/docs changelog.xml
 Log:
 Fix version #.
 
 What ever the next version is that is released from here, it is not going to be called 5.0.x.
 
 

I did refer to that with the "5.5" revision number, because the API 
isn't compatible, and because I wanted to tweak it for JDK 1.5 (or JDK 
5.0, whatever). So it's a lot of 5s.

 Revision  ChangesPath
 1.78  +1 -1  jakarta-tomcat-catalina/webapps/docs/changelog.xml
 
 Index: changelog.xml
 ===
 RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
 retrieving revision 1.77
 retrieving revision 1.78
 diff -u -r1.77 -r1.78
 --- changelog.xml	26 Jul 2004 15:39:13 -	1.77
 +++ changelog.xml	26 Jul 2004 17:04:04 -	1.78
 @@ -14,7 +14,7 @@
  
  
  
 -
 +

  

 

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

Re: TC 5: Support for multiple Coyote JK-Pools

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK 
pool at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor 
not only once, but for every Coyote JK pool configured in 
server.xml. For the second pool I get an exception when starting 
tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down 
correctly, and one of the two JK pools doesn't listen any more, 
but the second JK pool still listens and TC does not shut down. 
Retrying shutdown does not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?


Yes: use JDK 1.5 JMX instead of this code.


Are we going to switch to JDK1.5 ???
I missed this one.

Actually, I posted that we could consider switching to JDK 1.5, yes 
(I do really like that JDK). The idea is that I'm tweaking the API, 
so I would use the new stuff when rewriting code. I don't think it'll 
happen in the end, since not many people seem to be in favor of it.
Here, I was mentioning that using JDK 1.5 would be a workaround (as 
the connector registration moves out of the JVM).

Well, I like JDK1.5 as well - but I think we should follow the same 
path of keeping the base functionality available on lower VMs, and 
restrict 1.5 to individual components.

Not sure what you mean with "connector registration moves out of jvm" 
tough, but it sounds interesting :-)
Bad sentence, it should be "moves to the JVM". I don't know if you tried 
it, but there's a management.properties file that has all the options 
you could dream of to configure JMX remote :) Then you get fancy graphs 
without having to configure anything in Tomcat 
(http://mc4j.sourceforge.net/15Features_large.gif and the more "classic" 
http://mc4j.sourceforge.net/ss5_large.gif).

So it's less code in Tomcat for something a lot more powerful = I like 
it (even if I have to remove all the "enum" variables from my code).

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

Re: Mod_ajp initial

[Costin Manolache]

Mladen Turk wrote:
 

Costin Manolache wrote:
Mladen Turk wrote:
If I make a design flaw, and the entire project gets 
unusable, it will 

make it just something like mod_java, mod_warp, mod_jk and 
mod_jk2 are... Dead.
Nobody will get hanged for that.

I don't think the goal is to accumulate more mod_warp, 
mod_jk, mod_jk2 - but to learn from the past errors and do 
something better.


OK then, do you have some other proposition, or just saying what we all said
discussing this subject.
AFICR you said that you will have something to share, and I'd love to see
some other, perhaps better ideas.
No, I'm trying stuff on java side.
And just like with code - I don't think we are missing propositions or 
ideas. What is missing is an agreement over what features we are going 
to support ( and more exactly - not support ), as well as a clear plan 
on how to support them without spaghetti.

I think we do have agreement on droping IIS/iPlanet. We had agreement on 
droping pluggable protocol - but that's now back with the discussion on 
mod_proxy ( which also involves pluggable protocol ).

Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and 
requirements ( == goals ).

And at least in apache2 I remember they did spent the time to discuss 
this and figure out the best design ( and quite a few "creative" 
solutions were not accepted ). Take a look at apache filters, or APR.


We are discussing too, right? And if you follow the discussion, you will
find enough 'design leads'.
There is nothing in the source tree jet, and the thread is named 'initial'.
After all, I wrote that initial code in a single afternoon, so it's not such
a big deal.
Yes, we do have plenty of connectors, and most were written very fast - 
  mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy.

Having a 6th codebase - especially in the context of the growing 
agreement over mod_proxy as a long-term solution - is not what is missing.

My concern is that we are just repeating the history of the first 4 
connectors - by writting some initial code that solves the easy problem 
( sending requests to tomcat ), and hoping the rest can be added without 
getting back to spaghetti.

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

DO NOT REPLY [Bug 30325] - [PATCH] $CATALINA_HOME set unconditionally in bin/catalina.sh

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30325

[PATCH] $CATALINA_HOME set unconditionally in bin/catalina.sh

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|$CATALINA_HOME set  |[PATCH] $CATALINA_HOME set
   |unconditionally in  |unconditionally in
   |bin/catalina.sh |bin/catalina.sh



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 17:27 ---
Provided patch to fix the problem. Done on Tomcat 5.0.27 but works on 5.0.25 as
well.

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

DO NOT REPLY [Bug 30325] - $CATALINA_HOME set unconditionally in bin/catalina.sh

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30325

$CATALINA_HOME set unconditionally in bin/catalina.sh





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 17:24 ---
Created an attachment (id=12226)
Patch not to set $CATALINA_HOME if already defined (applies to bin/catalina.sh).

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

Re: Support for multiple Coyote JK-Pools

[Bill Barker]

- Original Message -
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 26, 2004 3:48 AM
Subject: TC 5: Support for multiple Coyote JK-Pools


> Am I right, that by design TC 5 only fully supports one Coyote JK pool
> at the moment?
>

Yes.  If at some point we decide to deprecate support for JK2, then we could
consider supporting multiple JK Connectors.  If you *really* need to have
multiple Connectors (and I can't see a usage case), try playing with the
jkHome attribute.

> I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
> org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not
> only once, but for every Coyote JK pool configured in server.xml. For
> the second pool I get an exception when starting tomcat (see below).
>
> When trying to stop TC, the Coyote HTTP pool is shut down correctly, and
> one of the two JK pools doesn't listen any more, but the second JK pool
> still listens and TC does not shut down. Retrying shutdown does not
> help, the process is still alive.
>
> Any plans (or work already done) to refactor JkMain/JkMX for 5.next?
>

Well, I believe the consensus is to deprecate JkMX in 5.next. It's pretty
outdated now, and it certainly doesn't belong in the Connector code.

> Rainer Jung
>
> Exception during start:
>
> 2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't
> load the MX4J http adapter
> javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor
>  at
mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123)
>  at
> mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054)
>  at
> mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002)
>  at
> mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978)
>  at org.apache.jk.common.JkMX.registerObject(JkMX.java:314)
>  at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157)
>  at org.apache.jk.common.JkMX.init(JkMX.java:268)
>  at org.apache.jk.server.JkMain.start(JkMain.java:339)
>  at
> org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193)
>  at
> org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527)
>  at
> org.apache.catalina.core.StandardService.start(StandardService.java:489)
>  at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
>  at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
>  at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:324)
>  at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284)
>  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422)
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

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

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

Re: [5.next] Progress, more ideas and native connector benchmarks

[Bill Barker]

I'll volunteer for the admin webapp stuff.  I enjoy deleting stuff from
there ;-).

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, July 26, 2004 9:27 AM
Subject: Re: [5.next] Progress, more ideas and native connector benchmarks


I committed a few things:
- The new deployer is getting there. Missing is the support for the
manager webapp, but this won't be too hard to write.
- I redid partially the naming. Now the NamingResource object is the
main object, and Context is not polluted.

My list is:
- Update manager webapp, and add support for it in HostConfig (incl JMX
registration).
- Remove Deployer and DefaultContext. The new stuff looks like a better
replacement.
- HTML host manager servlet (allows easily creating host and
preconfiguring them - ex: with the manager webapp installed, and a
default context file).
- Try to optimize startup time, if possible.
- As mentioned in my commit message, I don't think the dynamic updates
to the naming environment are useful. The code which does that is
relatively complex (although it's not as bad as before with the
ResourceParams). My opinion is that if something is not useful, then it
should go ;) Any comments on that fancy feature ?
- I'll have a lot of work updating the docs now :-P (I guess the fun is
nearly over :( )
- The admin webapp will need some tweaks after removing the DefaultContext.

The commit message on my last commit didn't seem to go through, so here
it is:
- As I discussed earlier, switch to a nicer looking syntax for naming
stuff, using setAllProperties. This simplifies the code a lot.
- Example:

- Remove the horrible ResourceParams, and add new objects for
transaction and resourceRefs.
- At the same time, big cleanup of the code.
- Removing the (completely useless) facading the Context was doing for
the NamingResources object. This is something I couldn't do
  in 4.1.x because we didn't want to change the API. The last thing I
didn't remove is some messaging stuff. What's that ?
- Some tweaking will likely be needed (for example, the save-to-XML code
needs to save all the extra properties). However, a lot
  of stuff won't need to be adjusted, as it was using NamingResources (I
don't think the naming support in the admin webapp is going
  to need anything).
- I'm wondering how useful it is to be able to dynamically update the
associated naming context. I think we should remove that, and
  just reload the webapp (since I think most webapps won't be able to
handle dynamic changes in the ENC). I'll post about that in my
  next progress email.

Rémy


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



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

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

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

RE: Mod_ajp initial

[Mladen Turk]

 

Costin Manolache wrote:
> 
> Mladen Turk wrote:
> > 
> > If I make a design flaw, and the entire project gets 
> unusable, it will 
> > make it just something like mod_java, mod_warp, mod_jk and 
> mod_jk2 are... Dead.
> > Nobody will get hanged for that.
> 
> 
> I don't think the goal is to accumulate more mod_warp, 
> mod_jk, mod_jk2 - but to learn from the past errors and do 
> something better.
> 

OK then, do you have some other proposition, or just saying what we all said
discussing this subject.
AFICR you said that you will have something to share, and I'd love to see
some other, perhaps better ideas.

> 
> Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and 
> requirements ( == goals ).
> 
> And at least in apache2 I remember they did spent the time to discuss 
> this and figure out the best design ( and quite a few "creative" 
> solutions were not accepted ). Take a look at apache filters, or APR.
>

We are discussing too, right? And if you follow the discussion, you will
find enough 'design leads'.
There is nothing in the source tree jet, and the thread is named 'initial'.

After all, I wrote that initial code in a single afternoon, so it's not such
a big deal.


MT.


smime.p7s
Description: S/MIME cryptographic signature

Re: Mod_ajp initial

[Remy Maucherat]

jean-frederic clere wrote:
We have noted that mod_proxy + mod_proxy_http are slow compared with 
mod_jk.
I think that the next step should be to try to find "why" instead 
writting a new modules. May be a quick hacked mod_proxy_ajp to replace 
mod_proxy_http is the first step.

Note that I am a bit reluctant to start a new module because I already 
had lost  a lot of time in mod_webapp ;-(
A lot of people lost time on various connectors, so you're not alone ;) 
(the list includes me with my old HTTP connector in Tomcat 4.0)

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

Re: [5.next] Progress, more ideas and native connector benchmarks

[Remy Maucherat]

I committed a few things:
- The new deployer is getting there. Missing is the support for the 
manager webapp, but this won't be too hard to write.
- I redid partially the naming. Now the NamingResource object is the 
main object, and Context is not polluted.

My list is:
- Update manager webapp, and add support for it in HostConfig (incl JMX 
registration).
- Remove Deployer and DefaultContext. The new stuff looks like a better 
replacement.
- HTML host manager servlet (allows easily creating host and 
preconfiguring them - ex: with the manager webapp installed, and a 
default context file).
- Try to optimize startup time, if possible.
- As mentioned in my commit message, I don't think the dynamic updates 
to the naming environment are useful. The code which does that is 
relatively complex (although it's not as bad as before with the 
ResourceParams). My opinion is that if something is not useful, then it 
should go ;) Any comments on that fancy feature ?
- I'll have a lot of work updating the docs now :-P (I guess the fun is 
nearly over :( )
- The admin webapp will need some tweaks after removing the DefaultContext.

The commit message on my last commit didn't seem to go through, so here 
it is:
- As I discussed earlier, switch to a nicer looking syntax for naming 
stuff, using setAllProperties. This simplifies the code a lot.
- Example:
   
 type="org.apache.catalina.UserDatabase"
  description="User database that can be updated and saved"
  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
 pathname="conf/tomcat-users.xml" />
- Remove the horrible ResourceParams, and add new objects for 
transaction and resourceRefs.
- At the same time, big cleanup of the code.
- Removing the (completely useless) facading the Context was doing for 
the NamingResources object. This is something I couldn't do
 in 4.1.x because we didn't want to change the API. The last thing I 
didn't remove is some messaging stuff. What's that ?
- Some tweaking will likely be needed (for example, the save-to-XML code 
needs to save all the extra properties). However, a lot
 of stuff won't need to be adjusted, as it was using NamingResources (I 
don't think the naming support in the admin webapp is going
 to need anything).
- I'm wondering how useful it is to be able to dynamically update the 
associated naming context. I think we should remove that, and
 just reload the webapp (since I think most webapps won't be able to 
handle dynamic changes in the ENC). I'll post about that in my
 next progress email.

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

Re: Mod_ajp initial

[Costin Manolache]

Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:

Of course, no one is forced to participate in development, but 
everyone is
welcome. The only question is do we have enough juice to make it 
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open 
source
after all, and it doesn't break nothing that already exists.

I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that 
exists" is not the only criteria used in apache. "Is it the best 
solution ?" can be used sometimes.

Well I've got more than one reason to object to current jk2 and jk.
This is not about objecting to current jk and jk2. They are where they 
are because of some design and requirement errors. The whole point is to 
avoid this. It should be obvious that adding important features as an 
after-tough and starting with "just code that doesn't break" instead of 
a sound requirements and design will likely lead to the same spaghetti 
and mess in the long run.


I said that some known Tomcat instances, Remy asked us to avoid the
old jk/jk2 naming, are set in Apache 2 by default, but nothing
prevent us to add new instance dynamically, via ajp_status or mod_status
or whatever (may be even via AJP/1.4).

Nothing prevented us to add any feature to mod_jk.x either.
3 years ago we didn't know all those requirements - few people were 
thinking at that time that tomcat will be used in "allways on" 
configurations. Now we do.


And if "dynamic config" is not on the list - then it won't solve the 
problem for people who really need apache+tomcat, i.e. many large 
sites with uptime requirements. Why confuse the people with yet 
another connector - and what hope can we have it will not have the 
same fate as mod_webapp ?

I'm handling sites requiring this kind of requirement and it's
high on my mod_ajp features wish list. When you operate sites which
works 24/24 and 7/7 and need to add horse power, it's a nightmare to
have to wait some period in the night to make the Apache server update
and restart.
Also admins may want to add some power for a short period of time,
so adding and removing such instances should be easy and quick.

Ok, so what is the plan to support this in mod_ajp ? Is this on the list 
of requirements - and for that matters, what is the list ? If it is, 
again, how do you plan to support it ? It's not a trivial issue, 
reconfiguration is very hard - and most likely to create a lot of spaghetti.


Well I'd like to resume the mod_ajp goal :
- an APR/Apache 2 specific module (no more mess with #ifdef for 30
  differents OS, we're in 2004).
- extract ajp stuff and put it in an ajp library, which could be used
  outside within the Apache 2.0 module, used by proxy_ajp and of
  course in others applications, ie ajp-bench.
- Study what has been done in mod_proxy to follow the start of art
  in Apache 2.x dev and make sure we could works with others AP2
  modules.
- Add/Remove/Update of Tomcat instances, and allow to attach/map them
  to URI and LB instances.
What about adding/updating of webapps ? Is this a feature that will 
never be added ( because if it will be and it is not part of the design 
- then we're back to spaghetti )


Costin will probably mention JMX/CMX support, but I think this
is something so important that it should be in HTTPD-dev and not
only in mod_ajp.
JMX is just a mean to an end. The goal is dynamic configuration ( i.e. 
without restart ).

Yes, it should be more available in httpd-dev ( they do have some with 
.htaccess, etc ), but we have few clear use cases they don't. Well - 
dynamic add/remove of webapps is quite trivial in apache, you can add 
cgis/php/etc without restarting the server even today.

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

DO NOT REPLY [Bug 30325] New: - $CATALINA_HOME set unconditionally in bin/catalina.sh

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30325

$CATALINA_HOME set unconditionally in bin/catalina.sh

   Summary: $CATALINA_HOME set unconditionally in bin/catalina.sh
   Product: Tomcat 5
   Version: 5.0.27
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


...whereas in bin/catalina.bat it is only set if not defined, as documented.

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

Re: [5.next] Progress, more ideas and native connector benchmarks

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation, 
but with finer control over what is exported/imported and pretty 
strong versioning. In addition osgi supports permissions on 
importing packages.
The reloading of modules is a bit more complicated than in jboss ( 
where you just change the jar ).
>From tomcat point of view - the implementation should be very 
similar with jboss.

What I like is the standardized and simpler behavior of class 
loaders, with ability to reload and upgrade any module ( like jboss ).


This classloader looks like it does stuff :)
I recommend plugging it in as usual, with the Loader interface. Is 
that ok ?

It should be, plugging tomcat into anything is usually simple.
The current tomcat loading mechanism - with 2 hierarchies of class 
loaders and the delegation hacks, plus the very rigid isolation 
between webapps - is far from perfect.

Again, it's a matter of interpreting the servlet spec - they do have 
some clear requirements on class loading, but I can't find any place 
where they forbid using other standards. I know adding an optional 
OSGI manifest could be controversial - but the benefits will be quite 
big. It would mean you can finally have arbitrary multiple versions of 
the same package, or have fine control ( using java permissions ) over 
what packages can be imported in a webapp or plugin. And it would mean 
an unified model for both webapps and plugins ( connectors, etc ).

The other very interesting aspects of eclipse are the extension point 
and the ( extreme ) laziness in loading plugins.

I imagined something a bit like that (with plenty of "CLs" each 
containing a particular version of a JAR), but:
- I got a big headache, and I don't think I'm capable of not screwing it 
up :D (so I decided to keep the current CL, which kinda works)
- I would take me a lot of time, and it wouldn't be useful to my 
employer, so they wouldn't be too happy in the end

I'd be really curious to see how you implemented all that stuff :)
Well, I don't have a lot of free time, so reimplementing all this stuff 
is not a choice, and I don't want the headaches :-).

Eclipse, oscar, knopflerfish ( last 2 with BSD licence ) already 
implement the class loaders - and there osgi standard is available in 
many other implementations ( sun embedded web server, etc ).

Jboss and eclipse use the same class loading mechanism - and the same 
model for "plugins". It would be really nice if jboss will make one 
extra step and add the missing features from osgi ( fine control of 
export/import and use the version information to match the loader ), and
even better if they would do this using the standard osgi manifest.

I think the granularity of jboss integration is a bit high - what I'm 
trying is to have each "plugin"( connector, auth, etc) as well as each 
webapp in a separate bundle - so you can add/remove/upgrade plugins just 
like eclipse does, without restart and with on-demand loading. ( I 
haven't checked the last jboss tough - maybe it alreay does that :-)

Anyway - it's work in progress, I don't know all details - the basic 
stuff obviouslty works ( since it works in jobss as well ), I can 
load/unload tomcat and individual connectors from eclipse console 
without problems.

Costin

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

Re: Mod_ajp initial

[Costin Manolache]

Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:

Of course, no one is forced to participate in development, but 
everyone is
welcome. The only question is do we have enough juice to make it 
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open 
source
after all, and it doesn't break nothing that already exists.

I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that 
exists" is not the only criteria used in apache. "Is it the best 
solution ?" can be used sometimes.

Well I've got more than one reason to object to current jk2 and jk.
This is not about objecting to current jk and jk2. They are where they 
are because of some design and requirement errors. The whole point is to 
avoid this. It should be obvious that adding important features as an 
after-tough and starting with "just code that doesn't break" instead of 
a sound requirements and design will likely lead to the same spaghetti 
and mess in the long run.



I said that some known Tomcat instances, Remy asked us to avoid the
old jk/jk2 naming, are set in Apache 2 by default, but nothing
prevent us to add new instance dynamically, via ajp_status or mod_status
or whatever (may be even via AJP/1.4).

Nothing prevented us to add any feature to mod_jk.x either.
3 years ago we didn't know all those requirements - few people were 
thinking at that time that tomcat will be used in "allways on" 
configurations.


And if "dynamic config" is not on the list - then it won't solve the 
problem for people who really need apache+tomcat, i.e. many large 
sites with uptime requirements. Why confuse the people with yet 
another connector - and what hope can we have it will not have the 
same fate as mod_webapp ?

I'm handling sites requiring this kind of requirement and it's
high on my mod_ajp features wish list. When you operate sites which
works 24/24 and 7/7 and need to add horse power, it's a nightmare to
have to wait some period in the night to make the Apache server update
and restart.
Also admins may want to add some power for a short period of time,
so adding and removing such instances should be easy and quick.

Ok, so what is the plan to support this in mod_ajp ? Is this on the list 
of requirements - and for that matters, what is the list ? If it is, 
again, how do you plan to support it ? It's not a trivial issue, 
reconfiguration is very hard - and most likely to create a lot of spaghetti.

It's not funny how we allways refuse to learn from our mistakes, and 
periodically repeat them


Well I'd like to resume the mod_ajp goal :
- an APR/Apache 2 specific module (no more mess with #ifdef for 30
  differents OS, we're in 2004).
- extract ajp stuff and put it in an ajp library, which could be used
  outside within the Apache 2.0 module, used by proxy_ajp and of
  course in others applications, ie ajp-bench.
- Study what has been done in mod_proxy to follow the start of art
  in Apache 2.x dev and make sure we could works with others AP2
  modules.
- Add/Remove/Update of Tomcat instances, and allow to attach/map them
  to URI and LB instances.
What about adding/updating of webapps ? Is this a feature that will 
never be added ( because if it will be and it is not part of the design 
- then we're back to spaghetti )


Costin will probably mention JMX/CMX support, but I think this
is something so important that it should be in HTTPD-dev and not
only in mod_ajp.
JMX is just a mean to an end. The goal is dynamic configuration ( i.e. 
without restart ).

Yes, it should be more available in httpd-dev ( they do have some with 
.htaccess, etc ), but we have few clear use cases they don't. Well - 
dynamic add/remove of webapps is quite trivial in apache, you can add 
cgis/php/etc without restarting the server even today.

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

Re: Mod_ajp initial

[Costin Manolache]

Mladen Turk wrote:
 

Costin Manolache wrote:
Mladen Turk wrote:

Of course, no one is forced to participate in development, but 
everyone is welcome.
The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open 
source after all, and it doesn't break nothing that already exists.
I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break 
anthing that exists" is not the only criteria used in apache. 
"Is it the best solution ?" can be used sometimes.


I must disagree with you.
There has been previous talks about 'wasting resources', that looks just
like some corporate manager would talk. 
You can not stop people seeking other solutions, trying to build something
better. It's the compete opposition of what IMO ASF stands for.
At least in Apache httpd project - it seems they are not willing to 
accept solutions that "just work", they also try to find the best 
solution and take the long-term into account.


If I make a design flaw, and the entire project gets unusable, it will make
it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead.
Nobody will get hanged for that.
It's not as simple. Users will have to invest time in learning and 
setting up this new tool, etc.

I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - 
but to learn from the past errors and do something better.


In any case - even if I'm no longer a very active tomcat 
committer, I think I can still -1 something that doesn't have 
a clear set of requirements, doesn't have a clear design that 
is able to support those features, doesn't have a 
configuration that is easy ( and by that I mean familiar for 
admins ), etc. You can ignore my vote if you want, but I'm 
pretty sure I am right.


What about free spirit, and creative mess, that produced something like
Apache2 and Tomcat.
Are we going to need to have a full set of requirements and marketing
analysis for each patch we make?
Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and 
requirements ( == goals ).

And at least in apache2 I remember they did spent the time to discuss 
this and figure out the best design ( and quite a few "creative" 
solutions were not accepted ). Take a look at apache filters, or APR.

This is not "just a patch" ( and even if it was - I think it's perfectly 
reasonable to think about the long-term goals on each patch - and not 
add features just because we can ). Usually spaghetti is the imediate 
result of accepting every feature.

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

Re: Dynamic updates and Apache v2.0

[Costin Manolache]

First, by "dynamic updates" I mean changes to apache2 config that don't 
require a restart. For example, .htaccess files provide such a thing ( 
for a different area ).

What updates ? There are several forms:
1.
- add a new worker to a pool ( for example - expect big load, you buy 
more hardware, etc ).

- gracefully remove a worker ( for upgrade for example ) - the 
implication is that sticky sessions will still go, no new sessions.

- change parameters of a worker ( like balancing factors ). That may 
include advanced balancing.

Note that for all this you don't actually need too much change on 
apache/mod_proxy - as long as you treat the "pool" as one entity, and 
maybe use a separate config file for the list of workers ( so you don't 
have to regenerate httpd.conf - which is quite difficult ). There are 
many ways to implement the communication between httpd processes and 
between apache and tomcat.

2.
- add more webapps and virtual servers - for example in the case of an ISP.
- reload webapps - that means some mappings and auth changes, in the 
case of tight integration you may want to have apache handle auth and 
mapping


Costin
Graham Leggett wrote:
Hi all,
I am starting a new thread for this, as it seems to be an important 
killer-app feature for any httpd v2.0 integration.

People have said the config should be dynamically configurable - which 
part of the config should be dynamically configurable?

In other words, would any of these senarios make sense:
- A potential pool of servers (IP address/port combinations) is defined, 
and httpd gracefully handles the case where a server is "missing". 
Adding a new server is as simple as starting it up on one of the 
predefined ip/ports combinations. An admin might configure an entire 
subnet as "tomcat servers", and then add and remove backend servers at 
will. Easy to do, but a bit limiting.

- httpd is informed via a special URL of updates to the servers on the 
backend, a bit like the management app in tomcat. This functionality 
might grow to being available to the whole httpd config. Being a URL, it 
would be pretected by standard mechanisms like SSL and basic 
authentication. Powerful, but a big change that will likely only appear 
in httpd v2.1 or v2.2.

- httpd polls the backend servers using the OPTIONS method (as was 
recommended recently). In the info returned, httpd learns of the 
intended weighting of the servers, whether a server needs to be removed 
gracefully from the pool, or whether other servers have been added to 
the pool and should be included in the config. Here httpd needs only to 
be told about just one backend server, which will "seed" httpd with info 
about all the other servers.

Out of the above three the third option seems to make the most sense. 
It's not very obtrusive, it can be used with backends other than tomcat. 
Actually updating the server list and weightings can be done via the 
tomcat management app, which already exists now (as opposed to a 
theoritical management app for httpd).

Thoughts?
Regards,
Graham
--

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

Re: TC 5: Support for multiple Coyote JK-Pools

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK 
pool at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor 
not only once, but for every Coyote JK pool configured in 
server.xml. For the second pool I get an exception when starting 
tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, 
and one of the two JK pools doesn't listen any more, but the second 
JK pool still listens and TC does not shut down. Retrying shutdown 
does not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?


Yes: use JDK 1.5 JMX instead of this code.


Are we going to switch to JDK1.5 ???
I missed this one.

Actually, I posted that we could consider switching to JDK 1.5, yes (I 
do really like that JDK). The idea is that I'm tweaking the API, so I 
would use the new stuff when rewriting code. I don't think it'll happen 
in the end, since not many people seem to be in favor of it.
Here, I was mentioning that using JDK 1.5 would be a workaround (as the 
connector registration moves out of the JVM).

Well, I like JDK1.5 as well - but I think we should follow the same path 
of keeping the base functionality available on lower VMs, and restrict 
1.5 to individual components.

Not sure what you mean with "connector registration moves out of jvm" 
tough, but it sounds interesting :-)


Costin

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

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[billbarker]

billbarker2004/07/26 10:04:04

  Modified:webapps/docs changelog.xml
  Log:
  Fix version #.
  
  What ever the next version is that is released from here, it is not going to be 
called 5.0.x.
  
  Revision  ChangesPath
  1.78  +1 -1  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.77
  retrieving revision 1.78
  diff -u -r1.77 -r1.78
  --- changelog.xml 26 Jul 2004 15:39:13 -  1.77
  +++ changelog.xml 26 Jul 2004 17:04:04 -  1.78
  @@ -14,7 +14,7 @@
   
   
   
  -
  +
 
   
 
  
  
  

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

RE: Mod_ajp initial

[Mladen Turk]

 

Graham Leggett wrote:
> Mladen Turk wrote:
> 
> > If I make a design flaw, and the entire project gets 
> unusable, it will 
> > make it just something like mod_java, mod_warp, mod_jk and 
> mod_jk2 are... Dead.
> > Nobody will get hanged for that.
> 
> Some code is always better than no code - at best, the code 
> will be good enough to fit the needs, and will end up in wide 
> use. At worst, the writers will say "we learned some lessons 
> from this" and try again.
>

True. A week or so before, none of us considered mod_proxy to be a good
candidate for ajp protocol. The main reason was presumed 'closeness' of
httpd developers to consider something like that. But, fortunately the
discussion has led to something that might have a great potential. If we
find enough support in httpd developers to accept the needed changes so we
can build something usable and powerful enough to fulfill our (and
presumably the users) needs, both mod_ajp and similar initiatives will be
useless.

There is also a question about 2.0 support, and that is the main reason for
concerns. If all the changes made to make the mod_proxy 'ajp enabled' gets
back propagated to 2.0 then we'll have all that is needed. Other option is
to either write something from jk/jk2 in a short period of time (mod_ajp)
that will fill in the gap of transition from 2.0 to 2.1, or still hanging
around jk and jk2.

In second case, I see the mod_ajp as a base for 2.0 users that will ease
them to transition to mod_proxy in 2.1. That means that we will try to
follow both the design and configuration look and feel the mod_proxy will
use.

And finally, when 2.1 gets the majority, the mod_ajp will be put in
maintaining mode (read; shot to be dead :)

MT.


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 30314] - Review new HostConfig and add something

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30314

Review new HostConfig and add something





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 16:58 ---
Yes, to talk about development issues, I think it's better.

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

DO NOT REPLY [Bug 30314] - Review new HostConfig and add something

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30314

Review new HostConfig and add something





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 16:47 ---
Hello Remy,

you mean that post better patches and comments at the tomdev list? 

regards
Peter

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

DO NOT REPLY [Bug 30279] - allowLinking attribute value is not preserved or ignored after context is reloaded

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30279

allowLinking attribute value is not preserved or ignored after context is reloaded





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 16:32 ---
The following was added in server.xml




Still symlink was not possible. If there is no prob with 5.0.24, could it be 
because I have installed Tomcat as root on my linux desktop?

Regards
Mahesh

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

DO NOT REPLY [Bug 30314] - Review new HostConfig and add something

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30314

Review new HostConfig and add something

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 16:41 ---
I committed some updated code, which seems to work, more or less. It's not done
yet, but it's getting there. Some of your suggestions were good, thanks (but you
should post them on tomcat-dev, probably).

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

Re: Mod_ajp initial

[Graham Leggett]

Mladen Turk wrote:
If I make a design flaw, and the entire project gets unusable, it will make
it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead.
Nobody will get hanged for that.
Some code is always better than no code - at best, the code will be good 
enough to fit the needs, and will end up in wide use. At worst, the 
writers will say "we learned some lessons from this" and try again.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Mod_ajp initial

[jean-frederic clere]

Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:

Of course, no one is forced to participate in development, but 
everyone is
welcome. The only question is do we have enough juice to make it 
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open 
source
after all, and it doesn't break nothing that already exists.

I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that 
exists" is not the only criteria used in apache. "Is it the best 
solution ?" can be used sometimes.

Well I've got more than one reason to object to current jk2 and jk.
jk works but the code is a huge spaghetti.
jk2 didn't works well and we could consider it dead before it even
reach production level. It's not a Henri/Mladen/Remy decision but
what Apache admins says about jk2 here and outside ASF.
I think mod_proxy + ajp + enhancements might be the right solution. It 
seems httpd people are willing to accept this into apache2, where it 
should be - and it seems very likely ( and reasonable ) they'll not 
accept another module that does almost the same thing ( but with 
different config and codebase ).

Mladen has allready provided some update for HTTPD-DEV and I'm
confident than Graham and Mladen will works together to improve
mod_proxy to make in fine something as fast as the current mod_jk.
I'm also not convinced that mod_ajp had been properly designed - I 
hear Henri mentioning "configurable non stop cluster" and "no 
restart", yet dynamic configuration was previously discarded by other 
people. And the config format suggests that little consideration was 
given to this - even the workers are configured in httpd.conf in a way 
that makes it hard to reconfigure with restarting apache. If dynamic 
reconfiguration ( even the minimal workers reconfig ) is on the list 
of features - adding it later will make the code as messy as mod_jk1 
and 2.

Well who said the Worker/Instance will have to be hardcoded in httpd.conf ?
I said that some known Tomcat instances, Remy asked us to avoid the
old jk/jk2 naming, are set in Apache 2 by default, but nothing
prevent us to add new instance dynamically, via ajp_status or mod_status
or whatever (may be even via AJP/1.4).
And if "dynamic config" is not on the list - then it won't solve the 
problem for people who really need apache+tomcat, i.e. many large 
sites with uptime requirements. Why confuse the people with yet 
another connector - and what hope can we have it will not have the 
same fate as mod_webapp ?

I'm handling sites requiring this kind of requirement and it's
high on my mod_ajp features wish list. When you operate sites which
works 24/24 and 7/7 and need to add horse power, it's a nightmare to
have to wait some period in the night to make the Apache server update
and restart.
Also admins may want to add some power for a short period of time,
so adding and removing such instances should be easy and quick.
In any case - even if I'm no longer a very active tomcat committer, I 
think I can still -1 something that doesn't have a clear set of 
requirements, doesn't have a clear design that is able to support 
those features, doesn't have a configuration that is easy ( and by 
that I mean familiar for admins ), etc. You can ignore my vote if you 
want, but I'm pretty sure I am right.

Well I'd like to resume the mod_ajp goal :
- an APR/Apache 2 specific module (no more mess with #ifdef for 30
  differents OS, we're in 2004).
- extract ajp stuff and put it in an ajp library, which could be used
  outside within the Apache 2.0 module, used by proxy_ajp and of
  course in others applications, ie ajp-bench.
- Study what has been done in mod_proxy to follow the start of art
  in Apache 2.x dev and make sure we could works with others AP2
  modules.
- Add/Remove/Update of Tomcat instances, and allow to attach/map them
  to URI and LB instances.
Costin will probably mention JMX/CMX support, but I think this
is something so important that it should be in HTTPD-dev and not
only in mod_ajp.
Thanks to comments
We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk.
I think that the next step should be to try to find "why" instead writting a new 
modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the 
first step.

Note that I am a bit reluctant to start a new module because I already had lost 
 a lot of time in mod_webapp ;-(


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


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

Re: Please take me off the list.

[sjafri]

>
> Hi,
>
> Why am I included on this list?
>
> Please remove me from the list.
>
> Thanks.
>
> colin
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




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

Dynamic updates and Apache v2.0

[Graham Leggett]

Hi all,
I am starting a new thread for this, as it seems to be an important 
killer-app feature for any httpd v2.0 integration.

People have said the config should be dynamically configurable - which 
part of the config should be dynamically configurable?

In other words, would any of these senarios make sense:
- A potential pool of servers (IP address/port combinations) is defined, 
and httpd gracefully handles the case where a server is "missing". 
Adding a new server is as simple as starting it up on one of the 
predefined ip/ports combinations. An admin might configure an entire 
subnet as "tomcat servers", and then add and remove backend servers at 
will. Easy to do, but a bit limiting.

- httpd is informed via a special URL of updates to the servers on the 
backend, a bit like the management app in tomcat. This functionality 
might grow to being available to the whole httpd config. Being a URL, it 
would be pretected by standard mechanisms like SSL and basic 
authentication. Powerful, but a big change that will likely only appear 
in httpd v2.1 or v2.2.

- httpd polls the backend servers using the OPTIONS method (as was 
recommended recently). In the info returned, httpd learns of the 
intended weighting of the servers, whether a server needs to be removed 
gracefully from the pool, or whether other servers have been added to 
the pool and should be included in the config. Here httpd needs only to 
be told about just one backend server, which will "seed" httpd with info 
about all the other servers.

Out of the above three the third option seems to make the most sense. 
It's not very obtrusive, it can be used with backends other than tomcat. 
Actually updating the server list and weightings can be done via the 
tomcat management app, which already exists now (as opposed to a 
theoritical management app for httpd).

Thoughts?
Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 30279] - allowLinking attribute value is not preserved or ignored after context is reloaded

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30279

allowLinking attribute value is not preserved or ignored after context is reloaded

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|allowLinking attribute value|allowLinking attribute value
   |is not preserved or ignored |is not preserved or ignored
   |after context is reloaded   |after context is reloaded



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:56 ---
You added what to server.xml?  There's nothing "following" your first 
paragraph.  Try 5.0.27 and update your bug report if it still fails in 5.0.27.

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

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

[remm]

remm2004/07/26 08:54:39

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
  Log:
  - When using the antiLocking flag, attempt to remove as much of the temp files when 
stopping.
  - As it was the case before, remove the work dir when undeploying.
  
  Revision  ChangesPath
  1.50  +28 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.49
  retrieving revision 1.50
  diff -u -r1.49 -r1.50
  --- ContextConfig.java26 Jul 2004 10:56:54 -  1.49
  +++ ContextConfig.java26 Jul 2004 15:54:38 -  1.50
  @@ -103,6 +103,12 @@
*/
   protected SAXParseException parseException = null;
   
  +
  +/**
  + * Original docBase.
  + */
  +protected String originalDocBase = null;
  +
   
   /**
* The string resources for this package.
  @@ -753,6 +759,11 @@
   String docBase = context.getDocBase();
   if (docBase == null)
   return;
  +if (originalDocBase == null) {
  +originalDocBase = docBase;
  +} else {
  +docBase = originalDocBase;
  +}
   File docBaseFile = new File(docBase);
   if (!docBaseFile.isAbsolute()) {
   docBaseFile = new File(appBase, docBase);
  @@ -773,7 +784,7 @@
   }
   
   File file = null;
  -if (context.getDocBase().toLowerCase().endsWith(".war")) {
  +if (docBase.toLowerCase().endsWith(".war")) {
   file = new File(System.getProperty("java.io.tmpdir"),
   deploymentCount++ + "-" + docBase + ".war");
   } else {
  @@ -1057,6 +1068,18 @@
   context.removeWrapperListener(wrapperListeners[i]);
   }
   
  +// Remove (partially) folders and files created by antiLocking
  +Host host = (Host) context.getParent();
  +String appBase = host.getAppBase();
  +String docBase = context.getDocBase();
  +if ((docBase != null) && (originalDocBase != null)) {
  +File docBaseFile = new File(docBase);
  +if (!docBaseFile.isAbsolute()) {
  +docBaseFile = new File(appBase, docBase);
  +}
  +ExpandWar.delete(docBaseFile);
  +}
  +
   ok = true;
   
   }
  @@ -1069,7 +1092,9 @@
   // Called from StandardContext.destroy()
   if (log.isDebugEnabled())
   log.debug(sm.getString("contextConfig.destroy"));
  -
  +String workDir = ((StandardContext) context).getWorkDir();
  +if (workDir != null)
  +ExpandWar.delete(new File(workDir));
   }
   
   
  
  
  

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

DO NOT REPLY [Bug 30274] - Servlet.service() for servlet jsp threw 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://issues.apache.org/bugzilla/show_bug.cgi?id=30274

Servlet.service() for servlet jsp threw exception





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:54 ---
Well, seeing as how the exception is in your code, maybe you can post 
upload.jsp?

As an aside, you might want to use the mailing list for bug discussions and 
assitance, as they are more widely and frequently read than the Bugzilla issues.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java WebappLoader.java

[remm]

remm2004/07/26 08:52:17

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java WebappLoader.java
  Log:
  - Update to use a flag for the anti JAR locking code. It isn't as foolproof as the 
other one, since you can't just delete a WAR or expanded
folder to undeploy (on Windows, of course).
  - I think the two flags together will cover all the needs.
  
  Revision  ChangesPath
  1.40  +37 -12
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- WebappClassLoader.java23 Jul 2004 22:40:11 -  1.39
  +++ WebappClassLoader.java26 Jul 2004 15:52:17 -  1.40
  @@ -160,6 +160,13 @@
   protected static final StringManager sm =
   StringManager.getManager(Constants.Package);
   
  +
  +/**
  + * Use anti JAR locking code, which does URL rerouting when accessing
  + * resources.
  + */
  +boolean antiJARLocking = false; 
  +
   
   // --- Constructors
   
  @@ -405,6 +412,22 @@
   
   
   /**
  + * @return Returns the antiJARLocking.
  + */
  +public boolean getAntiJARLocking() {
  +return antiJARLocking;
  +}
  +
  +
  +/**
  + * @param antiJARLocking The antiJARLocking to set.
  + */
  +public void setAntiJARLocking(boolean antiJARLocking) {
  +this.antiJARLocking = antiJARLocking;
  +}
  +
  +
  +/**
* If there is a Java SecurityManager create a read FilePermission
* or JndiPermission for the file directory path.
*
  @@ -1027,17 +1050,19 @@
   if (url != null) {
   // Locating the repository for special handling in the case 
   // of a JAR
  -ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
  -try {
  -String repository = entry.codeBase.toString();
  -if ((repository.endsWith(".jar")) 
  -&& (!(name.endsWith(".class" {
  -// Copy binary content to the work directory if not present
  -File resourceFile = new File(loaderDir, name);
  -url = resourceFile.toURL();
  +if (antiJARLocking) {
  +ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
  +try {
  +String repository = entry.codeBase.toString();
  +if ((repository.endsWith(".jar")) 
  +&& (!(name.endsWith(".class" {
  +// Copy binary content to the work directory if not present
  +File resourceFile = new File(loaderDir, name);
  +url = resourceFile.toURL();
  +}
  +} catch (Exception e) {
  +// Ignore
   }
  -} catch (Exception e) {
  -// Ignore
   }
   if (log.isDebugEnabled())
   log.debug("  --> Returning '" + url.toString() + "'");
  @@ -1766,7 +1791,7 @@
   }
   
   // Extract resources contained in JAR to the workdir
  -if (!(path.endsWith(".class"))) {
  +if (antiJARLocking && !(path.endsWith(".class"))) {
   byte[] buf = new byte[1024];
   File resourceFile = new File
   (loaderDir, jarEntry.getName());
  
  
  
  1.31  +3 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
  
  Index: WebappLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- WebappLoader.java 23 Jul 2004 22:40:11 -  1.30
  +++ WebappLoader.java 26 Jul 2004 15:52:17 -  1.31
  @@ -645,6 +645,8 @@
   classLoader = createClassLoader();
   classLoader.setResources(container.getResources());
   classLoader.setDelegate(this.delegate);
  +if (container instanceof StandardContext)
  +classLoader.setAntiJARLocking(((StandardContext) 
container).getAntiJARLocking());
   
   for (int i = 0; i < repositories.length; i++) {
   classLoader.addRepository(repositories[i]);
  
  
  

---

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[yoavs]

yoavs   2004/07/26 08:39:13

  Modified:catalina/src/share/org/apache/naming/factory
BeanFactory.java
   webapps/docs changelog.xml
  Log:
  Addressed Bugzilla 29831.
  
  Revision  ChangesPath
  1.3   +3 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java
  
  Index: BeanFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/factory/BeanFactory.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- BeanFactory.java  27 Feb 2004 14:58:54 -  1.2
  +++ BeanFactory.java  26 Jul 2004 15:39:13 -  1.3
  @@ -186,6 +186,9 @@
   } else if (propType.equals(Double.class) 
  || propType.equals(double.class)) {
   valueArray[0] = new Double(value);
  +} else if (propType.equals(Boolean.class)
  +   || propType.equals(boolean.class)) {
  +valueArray[0] = new Boolean(value);
   } else {
   throw new NamingException
   ("String conversion for property type '"
  
  
  
  1.77  +5 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.76
  retrieving revision 1.77
  diff -u -r1.76 -r1.77
  --- changelog.xml 26 Jul 2004 15:34:31 -  1.76
  +++ changelog.xml 26 Jul 2004 15:39:13 -  1.77
  @@ -36,6 +36,11 @@
 
   
 
  +
  +  
  +29831: Added support for Boolean property to BeanFactory. (yoavs)
  +  
  +
 
   
 
  
  
  

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

Re: TC 5: Support for multiple Coyote JK-Pools

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK 
pool at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor 
not only once, but for every Coyote JK pool configured in 
server.xml. For the second pool I get an exception when starting 
tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, 
and one of the two JK pools doesn't listen any more, but the second 
JK pool still listens and TC does not shut down. Retrying shutdown 
does not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?

Yes: use JDK 1.5 JMX instead of this code.

Are we going to switch to JDK1.5 ???
I missed this one.
Actually, I posted that we could consider switching to JDK 1.5, yes (I 
do really like that JDK). The idea is that I'm tweaking the API, so I 
would use the new stuff when rewriting code. I don't think it'll happen 
in the end, since not many people seem to be in favor of it.
Here, I was mentioning that using JDK 1.5 would be a workaround (as the 
connector registration moves out of the JVM).

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

DO NOT REPLY [Bug 29826] - Installation always exits with an error code.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29826

Installation always exits with an error code.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:37 ---
Thank you for reporting this bug and posting patches.  I've applied the 
setclasspath exit code patch.  The catalina.bat %current_dir% one was already 
applied in 5.0.26 or 5.0.27, so no action needed there.

In the future, if possible post diff patches rather than the full file.

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

RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[Michael Currie]

Can someone please unsubscribe me from this list?  I have sent about 20 email to 
unsubscribe and I'm still recieving them.

THanks

Mike Currie
Senior Web Developer
New Century Mortgage
Direct 949 743 7037
Mobile 949 279 4358
Fax 866 281 0360

> This electronic message transmission contains information from New Century which may 
> be confidential or privileged. This information is intended for the use of the 
> individuals or entity named in the message. If you are not the intended recipient, 
> be aware that any disclosure, copying, distribution or use of the contents of this 
> transmission is strictly prohibited. If you have received this electronic 
> transmission in error, please notify us immediately by telephone and delete the 
> message from your system. Thank you.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, July 26, 2004 8:35 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml


yoavs   2004/07/26 08:34:32

  Modified:catalina/src/bin setclasspath.bat
   webapps/docs changelog.xml
  Log:
  Addressed Bugzilla 29826.
  
  Revision  ChangesPath
  1.7   +2 -2  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat
  
  Index: setclasspath.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- setclasspath.bat  12 Feb 2004 21:38:56 -  1.6
  +++ setclasspath.bat  26 Jul 2004 15:34:31 -  1.7
  @@ -52,6 +52,6 @@
   goto end
   
   :exit
  -exit
  +exit /b 1
   
   :end
  
  
  
  1.76  +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.75
  retrieving revision 1.76
  diff -u -r1.75 -r1.76
  --- changelog.xml 23 Jul 2004 14:13:41 -  1.75
  +++ changelog.xml 26 Jul 2004 15:34:31 -  1.76
  @@ -29,6 +29,9 @@
 
   30245: Corrected Connector documentation to list "address" as a 
common attribute. (yoavs)
 
  +  
  +29826: Modified setclasspath.bat exit code to 1. (yoavs)
  +  
   
 
   
  
  
  

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



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

DO NOT REPLY [Bug 29831] - Support for boolean property in bean factory

[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://issues.apache.org/bugzilla/show_bug.cgi?id=29831

Support for boolean property in bean factory

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:40 ---
Done, thanks.

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

cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[yoavs]

yoavs   2004/07/26 08:34:32

  Modified:catalina/src/bin setclasspath.bat
   webapps/docs changelog.xml
  Log:
  Addressed Bugzilla 29826.
  
  Revision  ChangesPath
  1.7   +2 -2  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat
  
  Index: setclasspath.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- setclasspath.bat  12 Feb 2004 21:38:56 -  1.6
  +++ setclasspath.bat  26 Jul 2004 15:34:31 -  1.7
  @@ -52,6 +52,6 @@
   goto end
   
   :exit
  -exit
  +exit /b 1
   
   :end
  
  
  
  1.76  +3 -0  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.75
  retrieving revision 1.76
  diff -u -r1.75 -r1.76
  --- changelog.xml 23 Jul 2004 14:13:41 -  1.75
  +++ changelog.xml 26 Jul 2004 15:34:31 -  1.76
  @@ -29,6 +29,9 @@
 
   30245: Corrected Connector documentation to list "address" as a 
common attribute. (yoavs)
 
  +  
  +29826: Modified setclasspath.bat exit code to 1. (yoavs)
  +  
   
 
   
  
  
  

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

Re: Mod_ajp initial

[Henri Gomez]

Costin Manolache wrote:
Mladen Turk wrote:

Of course, no one is forced to participate in development, but 
everyone is
welcome. The only question is do we have enough juice to make it 
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all, and it doesn't break nothing that already exists.

I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that 
exists" is not the only criteria used in apache. "Is it the best 
solution ?" can be used sometimes.
Well I've got more than one reason to object to current jk2 and jk.
jk works but the code is a huge spaghetti.
jk2 didn't works well and we could consider it dead before it even
reach production level. It's not a Henri/Mladen/Remy decision but
what Apache admins says about jk2 here and outside ASF.
I think mod_proxy + ajp + enhancements might be the right solution. It 
seems httpd people are willing to accept this into apache2, where it 
should be - and it seems very likely ( and reasonable ) they'll not 
accept another module that does almost the same thing ( but with 
different config and codebase ).
Mladen has allready provided some update for HTTPD-DEV and I'm
confident than Graham and Mladen will works together to improve
mod_proxy to make in fine something as fast as the current mod_jk.
I'm also not convinced that mod_ajp had been properly designed - I hear 
Henri mentioning "configurable non stop cluster" and "no restart", yet 
dynamic configuration was previously discarded by other people. And the 
config format suggests that little consideration was given to this - 
even the workers are configured in httpd.conf in a way that makes it 
hard to reconfigure with restarting apache. If dynamic reconfiguration ( 
even the minimal workers reconfig ) is on the list of features - adding 
it later will make the code as messy as mod_jk1 and 2.
Well who said the Worker/Instance will have to be hardcoded in httpd.conf ?
I said that some known Tomcat instances, Remy asked us to avoid the
old jk/jk2 naming, are set in Apache 2 by default, but nothing
prevent us to add new instance dynamically, via ajp_status or mod_status
or whatever (may be even via AJP/1.4).
And if "dynamic config" is not on the list - then it won't solve the 
problem for people who really need apache+tomcat, i.e. many large sites 
with uptime requirements. Why confuse the people with yet another 
connector - and what hope can we have it will not have the same fate as 
mod_webapp ?
I'm handling sites requiring this kind of requirement and it's
high on my mod_ajp features wish list. When you operate sites which
works 24/24 and 7/7 and need to add horse power, it's a nightmare to
have to wait some period in the night to make the Apache server update
and restart.
Also admins may want to add some power for a short period of time,
so adding and removing such instances should be easy and quick.
In any case - even if I'm no longer a very active tomcat committer, I 
think I can still -1 something that doesn't have a clear set of 
requirements, doesn't have a clear design that is able to support those 
features, doesn't have a configuration that is easy ( and by that I mean 
familiar for admins ), etc. You can ignore my vote if you want, but I'm 
pretty sure I am right.
Well I'd like to resume the mod_ajp goal :
- an APR/Apache 2 specific module (no more mess with #ifdef for 30
  differents OS, we're in 2004).
- extract ajp stuff and put it in an ajp library, which could be used
  outside within the Apache 2.0 module, used by proxy_ajp and of
  course in others applications, ie ajp-bench.
- Study what has been done in mod_proxy to follow the start of art
  in Apache 2.x dev and make sure we could works with others AP2
  modules.
- Add/Remove/Update of Tomcat instances, and allow to attach/map them
  to URI and LB instances.
Costin will probably mention JMX/CMX support, but I think this
is something so important that it should be in HTTPD-dev and not
only in mod_ajp.
Thanks to comments
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30324] - ERROR [JkCoyoteHandler] Error in action code

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30324

ERROR [JkCoyoteHandler] Error in action code





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:29 ---
You might want to try a more recent version of tomcat.  4.1.0 is very old and 
the relevant code has changed numerous times since then.

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

DO NOT REPLY [Bug 30324] New: - ERROR [JkCoyoteHandler] Error in action code

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30324

ERROR [JkCoyoteHandler] Error in action code

   Summary: ERROR [JkCoyoteHandler] Error in action code
   Product: Tomcat 4
   Version: 4.1.0
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


keep getting this stack trace dump whenever i crank up catilina..

10:40:21,013 ERROR [JkCoyoteHandler] Error in action code
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654)
at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:435)
at org.apache.coyote.Response.action(Response.java:226)
at org.apache.coyote.Response.finish(Response.java:348)
at org.apache.coyote.tomcat4.OutputBuffer.close(OutputBuffer.java:324)
at org.apache.coyote.tomcat4.CoyoteResponse.finishResponse
(CoyoteResponse.java:486)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:198)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:309)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:615)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:677)
at java.lang.Thread.run(Thread.java:534)
10:40:21,043 ERROR [JkCoyoteHandler] Error in action code
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654)
at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:435)
at org.apache.coyote.Response.action(Response.java:226)
at org.apache.coyote.Response.finish(Response.java:348)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:314)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:387)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:615)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:677)
at java.lang.Thread.run(Thread.java:534)
10:40:21,043 ERROR [ChannelSocket] Error, processing connection
java.net.SocketException: Software caused connection abort: recv failed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:548)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:486)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:603)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:677)
at java.lang.Thread.run(Thread.java:534)
10:40:21,423 ERROR [JkCoyoteHandler] Error in action code
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457)
at or

RE: Mod_ajp initial

[Mladen Turk]

 

Costin Manolache wrote:
> 
> Mladen Turk wrote:
> 
> 
> > Of course, no one is forced to participate in development, but 
> > everyone is welcome.
> > The only question is do we have enough juice to make it official.
> > AFICT, Remy, Henri and myself are in favor.
> > But frankly I see no reason for someone to object, cause it's open 
> > source after all, and it doesn't break nothing that already exists.
> 
> I'm not in favor, quite the contrary.
> 
> And I thing there are reasons to object - "doesn't break 
> anthing that exists" is not the only criteria used in apache. 
> "Is it the best solution ?" can be used sometimes.
> 

I must disagree with you.
There has been previous talks about 'wasting resources', that looks just
like some corporate manager would talk. 
You can not stop people seeking other solutions, trying to build something
better. It's the compete opposition of what IMO ASF stands for.

If I make a design flaw, and the entire project gets unusable, it will make
it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead.
Nobody will get hanged for that.

> 
> In any case - even if I'm no longer a very active tomcat 
> committer, I think I can still -1 something that doesn't have 
> a clear set of requirements, doesn't have a clear design that 
> is able to support those features, doesn't have a 
> configuration that is easy ( and by that I mean familiar for 
> admins ), etc. You can ignore my vote if you want, but I'm 
> pretty sure I am right.
> 

What about free spirit, and creative mess, that produced something like
Apache2 and Tomcat.
Are we going to need to have a full set of requirements and marketing
analysis for each patch we make?

Thing you've  gone too far :(

Regards,
MT.



smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 30322] - Jsp's source directory in task Jasper2 for ant

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30322

Jsp's source directory in task Jasper2 for ant

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 15:06 ---
Use the jspFiles attribute to compiled specific files. The javadocs have more info.

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

Re: Mod_ajp initial

[Costin Manolache]

Mladen Turk wrote:

Of course, no one is forced to participate in development, but everyone is
welcome. 
The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all, and it doesn't break nothing that already exists.
I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that 
exists" is not the only criteria used in apache. "Is it the best 
solution ?" can be used sometimes.

I think mod_proxy + ajp + enhancements might be the right solution. It 
seems httpd people are willing to accept this into apache2, where it 
should be - and it seems very likely ( and reasonable ) they'll not 
accept another module that does almost the same thing ( but with 
different config and codebase ).

I'm also not convinced that mod_ajp had been properly designed - I hear 
Henri mentioning "configurable non stop cluster" and "no restart", yet 
dynamic configuration was previously discarded by other people. And the 
config format suggests that little consideration was given to this - 
even the workers are configured in httpd.conf in a way that makes it 
hard to reconfigure with restarting apache. If dynamic reconfiguration ( 
even the minimal workers reconfig ) is on the list of features - adding 
it later will make the code as messy as mod_jk1 and 2.

And if "dynamic config" is not on the list - then it won't solve the 
problem for people who really need apache+tomcat, i.e. many large sites 
with uptime requirements. Why confuse the people with yet another 
connector - and what hope can we have it will not have the same fate as 
mod_webapp ?

In any case - even if I'm no longer a very active tomcat committer, I 
think I can still -1 something that doesn't have a clear set of 
requirements, doesn't have a clear design that is able to support those 
features, doesn't have a configuration that is easy ( and by that I mean 
familiar for admins ), etc. You can ignore my vote if you want, but I'm 
pretty sure I am right.

Costin

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

Re: Mod_ajp initial

[Henri Gomez]

Graham Leggett wrote:
Henri Gomez wrote:
Peace on ASF :)

Indeed :)
well mod_ajp will probably goes a bit farther than mod_proxy + 
proxy_ajp since mod_proxy will allways relay static configuration, ie 
map some knowns URL to knowns Tomcat.

Why would mod_proxy always rely on a static configuration?
Don't forget that a lot of the features of mod_jk (the dynamic stuff 
especially) would be very much welcomed if they were added to the proxy 
framework. Don't think that the proxy code is cast in stone - it is not. 
The first patch for the scoreboard has already been contributed, and I'm 
waiting for a lack of objection, then the patch is going into httpd v2.1 
with a vote for a backport to v2.0.

Being able to dynamically configure backends other than just tomcat 
would be an extremely useful feature for people who use mod_perl, or 
CGI, or other application servers.
Well Tomcat's commiters, I think we found another friend on HTTPD-DEV :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 5: Support for multiple Coyote JK-Pools

[Costin Manolache]

Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK pool 
at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not 
only once, but for every Coyote JK pool configured in server.xml. For 
the second pool I get an exception when starting tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, 
and one of the two JK pools doesn't listen any more, but the second JK 
pool still listens and TC does not shut down. Retrying shutdown does 
not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?

Yes: use JDK 1.5 JMX instead of this code.

Are we going to switch to JDK1.5 ???
I missed this one.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30322] New: - Jsp's source directory in task Jasper2 for ant

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30322

Jsp's source directory in task Jasper2 for ant

   Summary: Jsp's source directory in task Jasper2 for ant
   Product: Tomcat 5
   Version: 5.0.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I use the Jasper2 task (ant 1.6.2) as specify in documentation,
I can't specify the directory of the .jsp file. He takes all files .jsp in 
the "uriroot".

I have a problem this comportement for 2 raisons :

1) Files .jsp in directory CVS don't be compiled ! (sometimes these files are 
not valide).
2) I have several directory containing Jsp file, I would like compile only 
directory.

I have change the JspC.java : add a new paramter in task Ant : srcDic.

What do you thing about my solution ?

Elisabeth J.


Index: JspC.java
===
RCS file: /home/cvspublic/jakarta-tomcat-
jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.80
diff -w -B -b -r1.80 JspC.java
141a142
> private String srcDir;

518a520,528
> // < /**
>  M2 : Spécifie le répertoire Source des fichiers Jsp
> */
> public void setSrcDir(String Dir) {
>  srcDir=Dir;
> }
> // M2>>
> 

830a841,844
> // <   String cvs = files[i].substring(files[i].lastIndexOf
('/') +1);
>   if (!cvs.equalsIgnoreCase("CVS"))
>   {

831a846,847
>   }
> // M1>>

875c891,895
< scanFiles( new File( uriRoot ));
---
> // <   if (srcDir == null) {srcDir=uriRoot;}
>   else {if (!(new File(srcDir)).isAbsolute()) 
{srcDir=uriRoot+"/"+srcDir;}}
> scanFiles( new File( srcDir ));
> // M2>>

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

Re: Mod_ajp initial

[Graham Leggett]

Henri Gomez wrote:
Peace on ASF :)
Indeed :)
well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp 
since mod_proxy will allways relay static configuration, ie map some 
knowns URL to knowns Tomcat.
Why would mod_proxy always rely on a static configuration?
Don't forget that a lot of the features of mod_jk (the dynamic stuff 
especially) would be very much welcomed if they were added to the proxy 
framework. Don't think that the proxy code is cast in stone - it is not. 
The first patch for the scoreboard has already been contributed, and I'm 
waiting for a lack of objection, then the patch is going into httpd v2.1 
with a vote for a backport to v2.0.

Being able to dynamically configure backends other than just tomcat 
would be an extremely useful feature for people who use mod_perl, or 
CGI, or other application servers.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Mod_ajp initial

[Henri Gomez]

Graham Leggett wrote:
Remy Maucherat wrote:
I think very few people are actually using mod_proxy instead of 
mod_jk. You've got to back your assertion with some kind of numbers, 
otherwise it's FUD.

As do you. The assertion was based on comments on this mailing list, but 
we've already established that there is a need for the ajp protocol, 
lets move on.

I disagree with your statements. Performance is first, as long as 
useability isn't too bad.

Then we must agree to disagree. In my experience, if something isn't 
usable, it doesn't get used, so any potential performance advantage is 
purely theoretical. Lack of usability is one of the biggest failures in 
many open source projects, and I don't want to see httpd fall into that 
trap.
Peace on ASF :)
mod_jk is used on many productions sites. From my experience, admins who
use jk are people who are experienced with Tomcat and as such trust jk
and get habbits with its configuration. Admins using mod_proxy to link
Apache to Tomcat are those who are more confortable with HTTPD
standard modules.
Up to Coyote, Tomcat HTTP stack was very slow and jk was mandatory for 
speed and stability. Now we have the choice even if jk is still faster
than mod_proxy and proxy_http, but I'm sure than when proxy_http will be 
using HTTP connections pool the difference will be minimal.

And I'm sure than Graham and others will boost mod_proxy+proxy_http :)

To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled 
with Apache, and with better configuration would clearly be useable 
enough (I think mod_jk 1.2 was actually good enough on many Unix 
platforms).

It would be different to the established configuration method for 
backend servers, thus causing comments like "why does ajp work 
differently to the rest of the server", and "why is the load balancing 
feature of ajp not available server wide?".
well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp 
since mod_proxy will allways relay static configuration, ie map some 
knowns URL to knowns Tomcat.

The next step is to be able to update URI Mapping and Tomcat defs
in real, to avoid a restart of a production server.
I know real productions case where the HTTPD server COULDN'T and
SHOULDN'T be restarted and when you add another Tomcat to the cluster,
for example to help support an increase of load. mod_ajp will help
these admins to have a configurable non-stop cluster 'controller'.
But for those without this requirement mod_proxy + proxy_ajp will be
a perfect combination.
I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and 
will try their best to use it, but you really need to relax your 
position from "-1 for your code if it doesn't use mod_proxy". You need 
to add "unless we find good reasons why it wouldn't work for us".

httpd exists for the use of end users, not for the private use of just 
the people you listed. If somebody is going to the effort of creating a 
module specifically for httpd v2.0, then I don't see why they wouldn't 
go to the effort of making it fit into the established framework properly.
Tomcat also exist for the use of end users. All ASF products are made
for users, not for hackers purposes. Read my statement about dynamic
configuration and you'll see it's something needed for admins.
Part of my pay job is managing Apache HTTPD and Tomcat servers and the
dynamic update is really something needed, because I don't want to see
one day commercial products installed since Apache HTTPD and Tomcats
couldn't sastify this need.
Yes, as many here I'd want to use ASF products, for real productions
situations, I'm not a hacker.
I think _you_ need to do some research into mod_proxy, how it is 
designed and exactly how it works before making statements about it's 
performance. By testing the mod_proxy_http module, and then making 
statements about mod_proxy (a totally different module) shows that you 
don't know how the proxy framework works.
We understand that mod_proxy is a kind of server in HTTPD, I also track 
new-httpd list and remember the mod_proxy genese, the pros and cons even
in HTTPD commiters.

Mladen, Graham, Bill, Henri, Remy, we're all ASF commiters and as such
we should works together to make ASF products better.
The only way is to learn from each others since there is also great
commiters in jakarta.
BTW, Mladen, who known very well Apache 2.0 allready send some comments,
fixes and patches for mod_proxy and proxy_http.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jk 1.2.6 release - need more binaries

[jean-frederic clere]

Henri Gomez wrote:
Hi to all,
For jk 1.2.6 the following binaries are allready available :
Windows (ISAPI/JK for AP 1.3.31/JK for AP2 2.0.50)
Linux (JK for Fedora Core 2 Apache 2.0.50, for Suse 8.0 Apache 2.0.50 
PPC, for Suse 9.1 Apache 2.0)

Solaris (JK for Apache 1.3.31 EAPI/STANDARD)
iSeries (AS/400 V5R2 and UP)
We need macosx and netware, solaris / Apache 2.x
I have done the solaris / Apache 2.x (with native compiler).
Thanks to commiters to upload them to Apache dist directory
and don't forget to sign the binaries with you PGP/GPG key.
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: Mod_ajp initial

[Graham Leggett]

Remy Maucherat wrote:
I think very few people are actually using mod_proxy instead of mod_jk. 
You've got to back your assertion with some kind of numbers, otherwise 
it's FUD.
As do you. The assertion was based on comments on this mailing list, but 
we've already established that there is a need for the ajp protocol, 
lets move on.

I disagree with your statements. Performance is first, as long as 
useability isn't too bad.
Then we must agree to disagree. In my experience, if something isn't 
usable, it doesn't get used, so any potential performance advantage is 
purely theoretical. Lack of usability is one of the biggest failures in 
many open source projects, and I don't want to see httpd fall into that 
trap.

To give an example, a mod_jk 1.2.x fully 
rewritten with APR, compiled with Apache, and with better configuration 
would clearly be useable enough (I think mod_jk 1.2 was actually good 
enough on many Unix platforms).
It would be different to the established configuration method for 
backend servers, thus causing comments like "why does ajp work 
differently to the rest of the server", and "why is the load balancing 
feature of ajp not available server wide?".

I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and 
will try their best to use it, but you really need to relax your 
position from "-1 for your code if it doesn't use mod_proxy". You need 
to add "unless we find good reasons why it wouldn't work for us".
httpd exists for the use of end users, not for the private use of just 
the people you listed. If somebody is going to the effort of creating a 
module specifically for httpd v2.0, then I don't see why they wouldn't 
go to the effort of making it fit into the established framework properly.

I think _you_ need to do some research into mod_proxy, how it is 
designed and exactly how it works before making statements about it's 
performance. By testing the mod_proxy_http module, and then making 
statements about mod_proxy (a totally different module) shows that you 
don't know how the proxy framework works.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

default charset for text/*

[Michael Südkamp]

Hello,

In our web-app that runs with Tomcat 4.1.29 we set the content-type to "text/xml" in a 
servlet that serves an XML file. The XML encoding normally is UTF-8. We observed that 
special characters show up wrong in the browser. Packet sniffing revealed that Tomcat 
changed the content-type to "text/xml;charset=ISO-8859-1" which was not the case with 
earlier Tomcat versions.

I looked up the bug database and the mailing list for this behaviour and read that 
Tomcat behaves like this for alle "text/*" content types where the charset is mising.

To fix this I can change the mime-type-definition in web.xml to 
"text/xml;charset=UTF-8" or add this in my servlet. But If my servlet has to serve 
ISO-8859-1 XML files that would be also wrong. Should I parse the resource prior to 
serving it in order to determine the encoding?

I cannot find the strong requirement to add the default charset in the HTTP spec. I 
read a discussion in the list that the JSP spec requires it - but also for a servlet? 
I think the charset is added by the Coyote connector so from the connector's point of 
view servlets and JSP-servlets are the same.

Doesn't it make sense to omit the default charset for XML files because XML files 
normally should carry their encoding in the header? Then the browser could get the 
encoding from there as it was done with earlier Tomcat versions.

What is your opionion?

Best Regards

Michael


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

RE: [Launcher] release 1.0

[Shapira, Yoav]

Hi,
This seems fine.  I'm a little surprised Tomcat has been using Launcher
all this time without a formal Launcher released ever made, but hey,
life is full of surprises right? ;)

Let me know if you need help from our side. (Saying that with my Tomcat
hat on).

Yoav Shapira
Millennium Research Informatics


>-Original Message-
>From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]
>Sent: Sunday, July 25, 2004 5:34 PM
>To: Jakarta Commons Developers List; Tomcat Developers List
>Cc: Jakarta Commons Users List
>Subject: [Launcher] release 1.0
>
>Launcher was imported into jakarta commons almost 2 years ago (25 okt
>2002) but never had a release. The thing missing was a simple example
>to get new users started.
>Alban Peignier contributed this example, I added it to CVS.
>
>So we're ready to release IMHO.
>The site is build using maven, the component (and example) is build
>using an ant build.
>dev-build can be found here:
>http://cvs.apache.org/~dirkv/builds/
>
>Unless somebody see a mayor problem I would like to start the release
>process for launcher, lets say release target date in 3 weeks.
>
>Is this enough review time for everybody?
>I'm especially looking at the tomcat team as they are the main users.
>Other RC testers are also invited of cource...
>
>(please reply to common-dev)
>
>-- Dirk
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]


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

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

[remm]

remm2004/07/26 03:56:55

  Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java ContextConfig.java ExpandWar.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Add logic for avoiding locking on Windows. This takes a very heavy handed 
approach, but after trying many other methods, I think it's the
only way to properly address the issue and allow real hot (re)deployment.
  - It's disabled by default, and there's a new antiResourceLocking attribute on 
Context.
  - I think I'll leave in the lighter anti JAR locking code in the CL, but disabled by 
default (and with another similar flag on Context). It could
address different needs, and is less intrusive, as the webapp stays where it is.
  
  Revision  ChangesPath
  1.37  +38 -17
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
  
  Index: HostConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- HostConfig.java   26 Jul 2004 08:09:19 -  1.36
  +++ HostConfig.java   26 Jul 2004 10:56:53 -  1.37
  @@ -496,15 +496,25 @@
   host.addChild(context);
   // Add the eventual unpacked WAR and all the resources which 
will be
   // watched inside it
  -if (isWar && unpackWARs && (context.getDocBase() != null)) {
  -File docBase = new File(context.getDocBase());
  +if (isWar && unpackWARs) {
  +String name = null;
  +String path = context.getPath();
  +if (path.equals("")) {
  +name = "ROOT";
  +} else {
  +if (path.startsWith("/")) {
  +name = path.substring(1);
  +} else {
  +name = path;
  +}
  +}
  +File docBase = new File(name);
   if (!docBase.isAbsolute()) {
  -docBase = new File(new File(host.getAppBase()), 
  -context.getDocBase());
  +docBase = new File(new File(host.getAppBase()), name);
   }
   deployedApp.redeployResources.put(docBase.getAbsolutePath(),
   new Long(docBase.lastModified()));
  -addWatchedResources(deployedApp, context);
  +addWatchedResources(deployedApp, docBase.getAbsolutePath(), 
context);
   }
   } catch (Throwable t) {
   log.error(sm.getString("hostConfig.deployDescriptor.error",
  @@ -642,14 +652,24 @@
   // If we're unpacking WARs, the docBase will be mutated after
   // starting the context
   if (unpackWARs && (context.getDocBase() != null)) {
  -File docBase = new File(context.getDocBase());
  +String name = null;
  +String path = context.getPath();
  +if (path.equals("")) {
  +name = "ROOT";
  +} else {
  +if (path.startsWith("/")) {
  +name = path.substring(1);
  +} else {
  +name = path;
  +}
  +}
  +File docBase = new File(name);
   if (!docBase.isAbsolute()) {
  -docBase = new File(new File(host.getAppBase()), 
  -context.getDocBase());
  +docBase = new File(new File(host.getAppBase()), name);
   }
   deployedApp.redeployResources.put(docBase.getAbsolutePath(),
   new Long(docBase.lastModified()));
  -addWatchedResources(deployedApp, context);
  +addWatchedResources(deployedApp, docBase.getAbsolutePath(), 
context);
   }
   } catch (Throwable t) {
   log.error(sm.getString("hostConfig.deployJar.error",
  @@ -722,7 +742,7 @@
   host.addChild(context);
   deployedApp.redeployResources.put(dir.getAbsolutePath(),
   new Long(dir.

jk 1.2.6 release - need more binaries

[Henri Gomez]

Hi to all,
For jk 1.2.6 the following binaries are allready available :
Windows (ISAPI/JK for AP 1.3.31/JK for AP2 2.0.50)
Linux (JK for Fedora Core 2 Apache 2.0.50, for Suse 8.0 Apache 2.0.50 
PPC, for Suse 9.1 Apache 2.0)

Solaris (JK for Apache 1.3.31 EAPI/STANDARD)
iSeries (AS/400 V5R2 and UP)
We need macosx and netware, solaris / Apache 2.x
Thanks to commiters to upload them to Apache dist directory
and don't forget to sign the binaries with you PGP/GPG key.
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mod_ajp initial

[Remy Maucherat]

Graham Leggett wrote:
Remy Maucherat wrote:
The framework itself could be designed in a way which would end up 
hurting performance. It did happen in Tomcat in the past, and I don't 
know about mod_proxy since I haven't looked at it, but it could happen.

All the framework does is determine that a proxy handler is 
responsible for servicing the request, and passes control to that 
proxy handler. Any performance problem will be proxy_ajp's problem.

I think you should be more open minded about a possible mod_ajp 
connector

This isn't about being "open minded", it's about being consistent 
through the design of httpd.

One of the most important features of mod_ajp, even more important 
than performance, is usability. If the configuration of mod_ajp is 
significantly different from the configration of proxy, it just adds 
confusion to end users.

mod_jk is already way too complex to be useful - which is why people 
are choosing proxy_http over mod_jk, even if mod_jk is faster.
I think very few people are actually using mod_proxy instead of mod_jk. 
You've got to back your assertion with some kind of numbers, otherwise 
it's FUD.
I disagree with your statements. Performance is first, as long as 
useability isn't too bad. To give an example, a mod_jk 1.2.x fully 
rewritten with APR, compiled with Apache, and with better configuration 
would clearly be useable enough (I think mod_jk 1.2 was actually good 
enough on many Unix platforms).

I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and 
will try their best to use it, but you really need to relax your 
position from "-1 for your code if it doesn't use mod_proxy". You need 
to add "unless we find good reasons why it wouldn't work for us".

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

Re: TC 5: Support for multiple Coyote JK-Pools

[Remy Maucherat]

Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK pool 
at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not 
only once, but for every Coyote JK pool configured in server.xml. For 
the second pool I get an exception when starting tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, 
and one of the two JK pools doesn't listen any more, but the second JK 
pool still listens and TC does not shut down. Retrying shutdown does 
not help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?
Yes: use JDK 1.5 JMX instead of this code.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

TC 5: Support for multiple Coyote JK-Pools

[Rainer Jung]

Am I right, that by design TC 5 only fully supports one Coyote JK pool 
at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not 
only once, but for every Coyote JK pool configured in server.xml. For 
the second pool I get an exception when starting tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, and 
one of the two JK pools doesn't listen any more, but the second JK pool 
still listens and TC does not shut down. Retrying shutdown does not 
help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?
Rainer Jung
Exception during start:
2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't 
load the MX4J http adapter
javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor
at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123)
at 
mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054)
at 
mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002)
at 
mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978)
at org.apache.jk.common.JkMX.registerObject(JkMX.java:314)
at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157)
at org.apache.jk.common.JkMX.init(JkMX.java:268)
at org.apache.jk.server.JkMain.start(JkMain.java:339)
at 
org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193)
at 
org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:489)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422)


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

Re: Mod_ajp initial

[Graham Leggett]

Remy Maucherat wrote:
The framework itself could be designed in a way which would end up 
hurting performance. It did happen in Tomcat in the past, and I don't 
know about mod_proxy since I haven't looked at it, but it could happen.
All the framework does is determine that a proxy handler is responsible 
for servicing the request, and passes control to that proxy handler. Any 
performance problem will be proxy_ajp's problem.

I think you should be more open minded about a possible mod_ajp 
connector
This isn't about being "open minded", it's about being consistent 
through the design of httpd.

One of the most important features of mod_ajp, even more important than 
performance, is usability. If the configuration of mod_ajp is 
significantly different from the configration of proxy, it just adds 
confusion to end users.

mod_jk is already way too complex to be useful - which is why people are 
choosing proxy_http over mod_jk, even if mod_jk is faster.

On the other side of the fence, we have yet to find out 
that mod_proxy will fully fit our needs.
Then I suggest looking at the mod_proxy source, and learning how it 
works. This will clear up the apparent confusion that exists between 
mod_proxy and proxy_http.

The key functions are proxy_handler() and the proxy_run_scheme_handler() 
hook.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Mod_ajp initial

[Mladen Turk]

 

Henri Gomez wrote:
> Bill Barker wrote:
> 
> > I'm with Graham on this.  Personally, I have very little 
> interest in a 
> > mod_ajp module, but I am interested in proxy_ajp, proxy_lb, 
> etc.  Of 
> > course, since j-t-c has long doubled as j-t-sandbox, this 
> means that 
> > I'm +0 for committing your stuff there.
> 
> Well Mladen has been quick to release this initial work and I 
> suspect it will be faster again to make a valid prototype.
>

Sure thing :-).

 
> Now we should know who could works on it ?
> 

Of course, no one is forced to participate in development, but everyone is
welcome. 
The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all, and it doesn't break nothing that already exists.

It will of course produce a lot of reusable code for any preferred
framework, that can only be a benefit in long run.

Simply speaking we will only have a jk/jk2 functionality in a full-blown
optimized Apache2 module.


MT.


smime.p7s
Description: S/MIME cryptographic signature

[PATCH] proxy lb support - step 1

[Mladen Turk]

Hi all,

There has been some serious discussion for building load balancing support
for mod_proxy.
Here is the first in series of patches that will enable this.

The patch adds lb support in scoreboard, so that statuses for each lb worker
can be calculated for each child process.
It uses optional function to retrieve the number of lb workers and
calculates the scoreboard size accordingly.

The other option is to rewrite the scoreboard functionality and use it
inside mod_proxy, but that will cause a strange shm locking observed on some
platforms using jk2 shared memory, cause we cannot create the shm in parent
process. 

Right now the lb_score only defines 1024 byte space, that can later be
replaced with real struct members once when the lb functionality gets
frozen.
For now we will simply cast that to the desired structure.

Regards,
MT.

Index: scoreboard.h
===
RCS file: /home/cvspublic/httpd-2.0/include/scoreboard.h,v
retrieving revision 1.51
diff -u -r1.51 scoreboard.h
--- scoreboard.h9 Feb 2004 20:38:21 -   1.51
+++ scoreboard.h26 Jul 2004 09:33:26 -
@@ -32,6 +32,7 @@
 #include "apr_thread_proc.h"
 #include "apr_portable.h"
 #include "apr_shm.h"
+#include "apr_optional.h"
 
 /* Scoreboard file, if there is one */
 #ifndef DEFAULT_SCOREBOARD
@@ -118,6 +119,7 @@
 typedef struct {
 int server_limit;
 int thread_limit;
+int lb_limit;
 ap_scoreboard_e sb_type;
 ap_generation_t running_generation;/* the generation of children which
  * should still be serving requests. */
@@ -135,6 +137,13 @@
  */
 };
 
+/* stuff which is lb specific */
+typedef struct lb_score lb_score;
+struct lb_score{
+/* TODO: make a real stuct from this */
+unsigned char data[1024];
+};
+
 /* Scoreboard is now in 'local' memory, since it isn't updated once created,
  * even in forked architectures.  Child created-processes (non-fork) will
  * set up these indicies into the (possibly relocated) shmem records.
@@ -143,6 +152,7 @@
 global_score *global;
 process_score *parent;
 worker_score **servers;
+lb_score **balancers;
 } scoreboard;
 
 typedef struct ap_sb_handle_t ap_sb_handle_t;
@@ -168,6 +178,7 @@
 AP_DECLARE(worker_score *) ap_get_scoreboard_worker(int x, int y);
 AP_DECLARE(process_score *) ap_get_scoreboard_process(int x);
 AP_DECLARE(global_score *) ap_get_scoreboard_global(void);
+AP_DECLARE(lb_score *) ap_get_scoreboard_lb(int child_num, int lb_num);
 
 AP_DECLARE_DATA extern scoreboard *ap_scoreboard_image;
 AP_DECLARE_DATA extern const char *ap_scoreboard_fname;
@@ -184,6 +195,13 @@
   * @return OK or DECLINE on success; anything else is a error
   */  
 AP_DECLARE_HOOK(int, pre_mpm, (apr_pool_t *p, ap_scoreboard_e sb_type))
+
+/**
+  * proxy load balancer
+  * @return the number of load balancer workers.
+  */  
+APR_DECLARE_OPTIONAL_FN(int, ap_proxy_lb_workers,
+(void));
 
 /* for time_process_request() in http_main.c */
 #define START_PREQUEST 1

Index: scoreboard.c
===
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.74
diff -u -r1.74 scoreboard.c
--- scoreboard.c9 Feb 2004 20:40:49 -   1.74
+++ scoreboard.c26 Jul 2004 10:02:36 -
@@ -59,12 +59,15 @@
   (apr_pool_t *p, ap_scoreboard_e sb_type),
   (p, sb_type),OK,DECLINED)
 
+static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_workers)
+*proxy_lb_workers;
+
 struct ap_sb_handle_t {
 int child_num;
 int thread_num;
 };
 
-static int server_limit, thread_limit;
+static int server_limit, thread_limit, lb_limit;
 static apr_size_t scoreboard_size;
 
 /*
@@ -89,9 +92,20 @@
 {
 ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
 ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit);
+
+if (!proxy_lb_workers)
+proxy_lb_workers = APR_RETRIEVE_OPTIONAL_FN(ap_proxy_lb_workers);
+if (proxy_lb_workers)
+lb_limit = proxy_lb_workers();
+else
+lb_limit = 0;
+
 scoreboard_size = sizeof(global_score);
 scoreboard_size += sizeof(process_score) * server_limit;
 scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
+if (lb_limit)
+scoreboard_size += sizeof(lb_score) * server_limit * lb_limit;
+
 return scoreboard_size;
 }
 
@@ -102,7 +116,8 @@
 
 ap_calc_scoreboard_size();
 ap_scoreboard_image = 
-calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *));
+calloc(1, sizeof(scoreboard) + server_limit * sizeof(worker_score *) +
+   server_limit * lb_limit * sizeof(lb_score *));
 more_storage = shared_score;
 ap_scoreboard_image->global = (global_score *)more_storage;
   

Re: Mod_ajp initial

[Henri Gomez]

Bill Barker wrote:
I'm with Graham on this.  Personally, I have very little interest in a
mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc.  Of course,
since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for
committing your stuff there.
Well Mladen has been quick to release this initial work and I suspect
it will be faster again to make a valid prototype.
Now we should know who could works on it ?

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

Re: Mod_ajp initial

[Henri Gomez]

Remy Maucherat wrote:
Graham Leggett wrote:
Remy Maucherat wrote:
Until I'm shown a mod_proxy (with HTTP) with performance close to 
mod_jk, my opinion is that we can't use it.

As I've pointed out already, mod_proxy is a framework. The performance 
numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do 
anything on it's own.

There is no reason why proxy_ajp would be any slower than mod_ajp.

The framework itself could be designed in a way which would end up 
hurting performance. It did happen in Tomcat in the past, and I don't 
know about mod_proxy since I haven't looked at it, but it could happen.

I think you should be more open minded about a possible mod_ajp 
connector (assuming it ends up being a quality connector), and block it 
on principle. On the other side of the fence, we have yet to find out 
that mod_proxy will fully fit our needs.
Well I think that we should consider mod_ajp as a jk rewriting for 
Apache 2.0 (2.1) using all APR/APACHE2.x power.

Since we plan to developp an AJP library, it will ease the task for
ajp_proxy and we could validate many points like this and have a
release rate independant from the HTTPD 2.0/2.1 rr.
Of course mod_proxy will be extended by Graham and I'm sure he'll
put more and more optimisation in it, giving a better proxy framework
to HTTPD 2.x.
And when ajp_proxy will be ASF production level ready, it could be
included in HTTPD tree.
After that we could probably stop mod_ajp or use it as a features labs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30291] - Wrong smap in expressions and scriptlets

[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://issues.apache.org/bugzilla/show_bug.cgi?id=30291

Wrong smap in expressions and scriptlets





--- Additional Comments From [EMAIL PROTECTED]  2004-07-26 09:23 ---
Created an attachment (id=12217)
zip with files

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

Re: Mod_ajp initial

[Remy Maucherat]

Graham Leggett wrote:
Remy Maucherat wrote:
Until I'm shown a mod_proxy (with HTTP) with performance close to 
mod_jk, my opinion is that we can't use it.

As I've pointed out already, mod_proxy is a framework. The performance 
numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do 
anything on it's own.

There is no reason why proxy_ajp would be any slower than mod_ajp.
The framework itself could be designed in a way which would end up 
hurting performance. It did happen in Tomcat in the past, and I don't 
know about mod_proxy since I haven't looked at it, but it could happen.

I think you should be more open minded about a possible mod_ajp 
connector (assuming it ends up being a quality connector), and block it 
on principle. On the other side of the fence, we have yet to find out 
that mod_proxy will fully fit our needs.

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

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

[remm]

remm2004/07/26 01:09:21

  Modified:catalina/src/share/org/apache/catalina/startup
HostConfig.java ContextRuleSet.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java
   catalina/src/share/org/apache/catalina Context.java
  Added:   catalina/src/conf context.xml
  Log:
  - Add code to handle resource relaoding.
  - Add one extra element to Context (I couldn't find a way to avoid it).
  - Add a global context.xml file, to define two basic reload resources.
  - Now, I'll do the new anti locking code.
  
  Revision  ChangesPath
  1.36  +40 -27
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
  
  Index: HostConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- HostConfig.java   25 Jul 2004 23:35:37 -  1.35
  +++ HostConfig.java   26 Jul 2004 08:09:19 -  1.36
  @@ -464,28 +464,28 @@
   // Assume this is a configuration descriptor and deploy it
   log.debug(sm.getString("hostConfig.deployDescriptor", files[i]));
   try {
  -Context newContext = null;
  +Context context = null;
   synchronized (digester) {
  -newContext = (Context) digester.parse(contextXml);
  +context = (Context) digester.parse(contextXml);
   }
  -if (newContext instanceof Lifecycle) {
  +if (context instanceof Lifecycle) {
   Class clazz = Class.forName(host.getConfigClass());
   LifecycleListener listener =
   (LifecycleListener) clazz.newInstance();
  -((Lifecycle) newContext).addLifecycleListener(listener);
  +((Lifecycle) context).addLifecycleListener(listener);
   }
  -newContext.setConfigFile(contextXml.getAbsolutePath());
  -newContext.setPath(contextPath);
  +context.setConfigFile(contextXml.getAbsolutePath());
  +context.setPath(contextPath);
   // Add the context XML to the list of watched files
   deployedApp.reloadResources.put
   (contextXml.getAbsolutePath(), new 
Long(contextXml.lastModified()));
   // Add the associated docBase to the redeployed list if it's a 
WAR
   boolean isWar = false;
  -if (newContext.getDocBase() != null) {
  -File docBase = new File(newContext.getDocBase());
  +if (context.getDocBase() != null) {
  +File docBase = new File(context.getDocBase());
   if (!docBase.isAbsolute()) {
   docBase = new File(new File(host.getAppBase()), 
  -newContext.getDocBase());
  +context.getDocBase());
   }
   deployedApp.redeployResources.put(docBase.getAbsolutePath(),
   new Long(docBase.lastModified()));
  @@ -493,21 +493,18 @@
   isWar = true;
   }
   }
  -host.addChild(newContext);
  +host.addChild(context);
   // Add the eventual unpacked WAR and all the resources which 
will be
   // watched inside it
  -if (isWar && unpackWARs && (newContext.getDocBase() != null)) {
  -File docBase = new File(newContext.getDocBase());
  +if (isWar && unpackWARs && (context.getDocBase() != null)) {
  +File docBase = new File(context.getDocBase());
   if (!docBase.isAbsolute()) {
   docBase = new File(new File(host.getAppBase()), 
  -newContext.getDocBase());
  +context.getDocBase());
   }
   deployedApp.redeployResources.put(docBase.getAbsolutePath(),
   new Long(docBase.lastModified()));
  -// FIXME: Add the list of reload resources as given by the 
context
  -//This list would by default contain 
/WEB-INF/web.xml and
  -///META-INF/context.xml
  -//Add new element i

RE: [GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 success

[Microsoft UK Graduate Recruitment]

Please take me off this mail list.

Many Thanks

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 25 July 2004 10:46
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: jakarta-tomcat-5/jakarta-tomcat-5 success

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project jakarta-tomcat-5 *no longer* has an issue.
Project State : 'Success'

Full details are available at:

 
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/i
ndex.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Jar [naming-resources.jar] identifier set to jar basename:
[naming-resources]
 -DEBUG- Jar [servlets-default.jar] identifier set to jar basename:
[servlets-default]
 -DEBUG- Jar [naming-common.jar] identifier set to jar basename:
[naming-common]
 -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina]
 -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap]
 -DEBUG- Jar [servlets-common.jar] identifier set to jar basename:
[servlets-common]
 -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename:
[servlets-invoker]
 -DEBUG- Dependency on javamail exists, no need to add for property
mail.jar.
 -DEBUG- Dependency on jaf exists, no need to add for property
activation.jar.
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to
add for property servlet-api.jar.
 -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add
for property jsp-api.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property
xercesImpl.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property
xml-apis.jar.
 -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for
property tomcat-util.jar.
 -DEBUG- Dependency on commons-el exists, no need to add for property
commons-el.jar.
 -DEBUG- Dependency on commons-logging exists, no need to add for
property commons-logging-api.jar.
 -DEBUG- Dependency on commons-modeler exists, no need to add for
property commons-modeler.jar.
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jsse exists, no need to add for property
jsse.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar.
 -DEBUG- Dependency on jmx exists, no need to add for property
jmx-tools.jar.
 -DEBUG- Dependency on jndi exists, no need to add for property
jndi.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for
property regexp.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for
property regexp.jar.
 -DEBUG- Dependency on javamail exists, no need to add for property
mail.home.
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for
property tomcat-coyote.home.
 -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add
for property jasper.home.
 -DEBUG- Dependency on jaf exists, no need to add for property
activation.home.
 -DEBUG- Dependency on commons-modeler exists, no need to add for
property commons-modeler.home.
 -DEBUG- Dependency on commons-daemon exists, no need to add for
property commons-daemon.jsvc.tar.gz.
 -DEBUG- Dependency on jakarta-struts exists, no need to add for
property struts.home.
 -INFO- Enable "verbose" output, due to 1 previous error(s).


The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/g
ump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Success
Elapsed: 2 mins 41 secs
Command Line: java -Djava.awt.headless=true
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/buil
d/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build
/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xala
n-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/extern
al/build/xml-apis.jar org.apache.tools.ant.Main -verbose
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml
-Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet--
-Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr1
52/dist/lib/jsp-api.jar
-Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar
-Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakar
ta-regexp-20040725.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3
-Dant.home=/usr/local/gump/public/workspace/ant/dist
-Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commo
ns/collections/build/commons-collections-20040725.jar
-Dxml-apis.jar=/usr/local/gump/public/workspace