RE: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

[Mladen Turk]

> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, August 10, 2002 2:04 AM
> To: Tomcat Dev List
> Subject: Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
> 
> 
> Doesn't mod_rewrite do what you want here? In combination 
> with mod_proxy, it can rewrite URL to URL as well, so you can 
> get the resulting URL back in mod_jk and then just use normal 
> mappings. Or maybe I'm on a totally wrong track here...
> 

True (I think) for the positive assertions, but:

[uri:/examples/*]
#matches entire app

[uri:/examples/(?!\.(gif|jpe?g|png)$)]
#matches everything except .gif, .jpg, .jpeg, .png

The entire purpose is to be able to _disallow_ certain mappings in the
already mapped application.
I'm afraid that the mod_proxy cannot be used for such a thing, cause the
first mapping will forcibly drive all the examples context through the
TC.
At first I was trying (before the pcre idea) to use the simple matching
like :

[uri:/examples/*]

[uri:!/examples/*.jpg]

...etc

This is can be parsed without using pcre (using apr_fnmatch), but what
about more complex schemas involving directories and file extensions,
not only files.
On the other hand, we can use the mod_rewrite/mod_proxy only with the
Apache, and we want to be portable thought.

MT.


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

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

[amyroh]

amyroh  2002/08/09 19:40:36

  Modified:catalina/src/share/org/apache/catalina/mbeans
mbeans-descriptors.xml
  Log:
  Change CoyoteConnector MBean to use o.a.c.tomcat5.CoyoteConnector instead
  of o.a.c.tomcat4.CoyoteConnector.
  Also, alphabetize MBeans so it's easier to read.
  
  Revision  ChangesPath
  1.3   +59 -64
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml
  
  Index: mbeans-descriptors.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mbeans-descriptors.xml9 Aug 2002 02:07:12 -   1.2
  +++ mbeans-descriptors.xml10 Aug 2002 02:40:36 -  1.3
  @@ -11,25 +11,6 @@
   
   
   
  -  
  -
  -
  -
  -
  -
  -  
  -
  -
 
   
   
   
  @@ -238,7 +219,7 @@
 description="Implementation of a Coyote connector"
  domain="Catalina"
   group="Connector"
  - type="org.apache.coyote.tomcat4.CoyoteConnector">
  + type="org.apache.coyote.tomcat5.CoyoteConnector">
   
 
  + type="java.lang.String"/>
   
 
  + type="java.lang.String"/>
   

  -  
  + type="java.lang.String"/>
  +
 
  + type="int"/>
   
   
   
   
   
  @@ -1360,7 +1341,7 @@
 description="MBean Name of the component to be removed"
type="java.lang.String"/>
   
  -
  +
   
   
   
   
   
   
   
  @@ -1701,6 +1682,39 @@
   
 
   
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
   
 
   
  -
  -  
  -
  -
  -
  -
  + type="org.apache.catalina.valves.RequestDumperValve">
   
   
   
  -
 
   
  -
  -  
  + type="org.apache.catalina.valves.RequestListenerValve">
   
   
   
  -
 
   
   
  @@ -1944,7 +1939,7 @@
type="boolean"/>
   
   
  @@ -2062,7 +2057,7 @@
   
 
   
  -  
  +
 
   
 
  -  
  +
   
 mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

[Bojan Smojver]

Doesn't mod_rewrite do what you want here? In combination with
mod_proxy, it can rewrite URL to URL as well, so you can get the
resulting URL back in mod_jk and then just use normal mappings. Or maybe
I'm on a totally wrong track here...

As for IIS, dunno, don't care ;-)

Bojan

On Fri, 2002-08-09 at 21:07, Mladen Turk wrote:
> Hi,
> 
> Remember the last month advanced URI space resolution I proposed?
> 
> Well, I've been working on that for a week or so, and found myself doing
> things that are more or less regular expression matching of request uri.
> Even existing uri_map code has a trace of that (matching star for
> example), so IMO (since we are matching things) we could use the regex
> code as a general uri->file space matching solution. That way the users
> will be able to use the same syntax as for the  or
> mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE
> cases.
> 
> The major drawback of that is that we'll need the pcre library, either
> one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by
> Henry Spencer). Since the same should be used with the IIS and other
> platforms, I suggest that we use the one from Apache 2.0.
> 
> Using pcre will introduce the need for build process changes (only 2.0
> can use the proposed pcre from its own build) and we'll need the
> pcre.lib.
> 
> Thoughts?
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/core JkHandler.java

[costin]

costin  2002/08/09 13:54:24

  Modified:jk/java/org/apache/jk/server JkMain.java
   jk/java/org/apache/jk/core JkHandler.java
  Log:
  More getters and improvements for nice JMX view..
  
  Revision  ChangesPath
  1.29  +56 -9 
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
  
  Index: JkMain.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- JkMain.java   24 Jul 2002 22:13:06 -  1.28
  +++ JkMain.java   9 Aug 2002 20:54:23 -   1.29
  @@ -115,6 +115,7 @@
   
   public JkMain()
   {
  +JkMain.jkMain=this;
   modules.put("channelSocket", "org.apache.jk.common.ChannelSocket");
   modules.put("channelUnix", "org.apache.jk.common.ChannelUn");
   modules.put("channelJni", "org.apache.jk.common.ChannelJni");
  @@ -124,6 +125,11 @@
   modules.put("request","org.apache.jk.common.HandlerRequest");
   modules.put("container","org.apache.jk.common.HandlerRequest");
   }
  +
  +public static JkMain getJkMain() {
  +return jkMain;
  +}
  +
   //  Setting 
   
   /** Load a .properties file into and set the values
  @@ -138,6 +144,10 @@
   }
   }
   
  +public String getPropertiesFile() {
  +return propFile;
  +}
  +
   /** Set a name/value as a jk2 property
*/
   public void setProperty( String n, String v ) {
  @@ -159,6 +169,10 @@
   props.put( "handler.channel.className",name);
   }
   
  +public String getChannelClassName() {
  +return (String)props.get( "handler.channel.className");
  +}
  +
   /**
* Set the workerClassName that will handle the request.
* ( sort of 'pivot' in axis :-)
  @@ -167,6 +181,10 @@
   props.put( "handler.container.className",name);
   }
   
  +public String getWorkerClassName() {
  +return (String)props.get( "handler.container.className");
  +}
  +
   /** Set the base dir of jk2. ( including WEB-INF if in a webapp ).
*  We'll try to guess it from classpath if none is set ( for
*  example on command line ), but if in a servlet environment
  @@ -176,22 +194,36 @@
   public void setJkHome( String s ) {
   wEnv.setJkHome(s);
   }
  +
  +public String getJkHome() {
  +return wEnv.getJkHome();
  +}
   
   String out;
   String err;
  +File propsF;
   
   public void setOut( String s ) {
   this.out=s;
   }
   
  +public String getOut() {
  +return this.out;
  +}
  +
   public void setErr( String s ) {
   this.err=s;
   }
   
  +public String getErr() {
  +return this.err;
  +}
  +
   //  Initialization 
   
   public void init() throws IOException
   {
  +long t1=System.currentTimeMillis();
   if(null != out) {
   PrintStream outS=new PrintStream(new FileOutputStream(out));
   System.setOut(outS);
  @@ -215,17 +247,19 @@
   if( ! conf.exists() )
   conf=new File( home, "etc" );
   
  -File propsF=new File( conf, "jk2.properties" );
  +propsF=new File( conf, "jk2.properties" );
   
   if( propsF.exists() ) {
  -log.info("Starting Jk2, base dir= " + home + " conf=" + propsF );
  +log.debug("Starting Jk2, base dir= " + home + " conf=" + propsF );
   setPropertiesFile( propsF.getAbsolutePath());
   } else {
  -log.info("Starting Jk2, base dir= " + home );
  +log.debug("Starting Jk2, base dir= " + home );
   if( log.isWarnEnabled() )
   log.warn( "No properties file found " + propsF );
   }
   }
  +long t2=System.currentTimeMillis();
  +initTime=t2-t1;
   }
   
   static String defaultHandlers[]= { "request",
  @@ -258,6 +292,7 @@
   
   public void start() throws IOException
   {
  +long t1=System.currentTimeMillis();
   // We must have at least 3 handlers:
   // channel is the 'transport'
   // request is the request processor or 'global' chain
  @@ -300,10 +335,12 @@
   }
   
   started=true;
  -long initTime=System.currentTimeMillis() - start_time;
  +long t2=System.currentTimeMillis();
  +startTime=t2-t1;
   
   this.saveProperties();
  -log.info("Jk running ID=" + wEnv.getLocalId() + " ... init time=" + 
initTime + " ms");
  +log.info("Jk running ID=" + wEnv.getLocalId() + " time=" + ini

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java

[costin]

costin  2002/08/09 13:53:21

  Modified:jk/java/org/apache/jk/common JkMX.java
  Log:
  Update to match the fixes in DynamicMBeanProxy.
  
  Register JkMain as an mbean.
  
  Revision  ChangesPath
  1.6   +6 -17 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java
  
  Index: JkMX.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JkMX.java 8 Aug 2002 18:19:53 -   1.5
  +++ JkMX.java 9 Aug 2002 20:53:21 -   1.6
  @@ -63,6 +63,7 @@
   import java.util.*;
   
   import org.apache.jk.core.*;
  +import org.apache.jk.server.JkMain;
   
   import javax.management.*;
   
  @@ -103,20 +104,6 @@
   public String getHost() {
   return host;
   }
  -
  -public void createMBean( Object proxy, String name ) {
  -try {
  -DynamicMBeanProxy mbean=new DynamicMBeanProxy();
  -mbean.setReal( proxy );
  -if( name!=null ) {
  -mbean.setName( name );
  -}
  -
  -mbean.registerMBean( "jk2" );
  -} catch( Throwable t ) {
  -log.error( "Error creating mbean ", t );
  -}
  -}
   
   /*  Start/stop  */
   ObjectName serverName=null;
  @@ -205,15 +192,17 @@
   try {
   Class c=Class.forName( "org.apache.log4j.jmx.HierarchyDynamicMBean" 
);
   Object o=c.newInstance();
  -log.info("Registering the root hierarchy for JMX ");
  +log.info("Registering the JMX hierarchy for Log4J ");
   mserver.registerMBean(o, new ObjectName("log4j:hierarchy=default"));
   } catch( Throwable t ) {
   log.info("Can't enable log4j mx");
   }
   
  +DynamicMBeanProxy.createMBean( JkMain.getJkMain(), "jk2", "name=JkMain" 
); 
  +
   for( int i=0; i< wEnv.getHandlerCount(); i++ ) {
   JkHandler h=wEnv.getHandler( i );
  -createMBean( h, h.getName() );
  +DynamicMBeanProxy.createMBean( h, "jk2", "name=" + h.getName() );
   }
   
   } catch( Throwable t ) {
  @@ -223,7 +212,7 @@
   
   public void addHandlerCallback( JkHandler w ) {
   if( w!=this ) {
  -createMBean( w, w.getName() );
  +DynamicMBeanProxy.createMBean( w, "jk2", "name=" + w.getName() );
   }
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java

[costin]

costin  2002/08/09 13:52:37

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Add getters for various fields, added a 'requestCount' attribute,
  make thing prettier for the JMX view.
  
  Revision  ChangesPath
  1.21  +45 -3 
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- ChannelSocket.java8 Aug 2002 18:19:04 -   1.20
  +++ ChannelSocket.java9 Aug 2002 20:52:37 -   1.21
  @@ -109,6 +109,8 @@
   int linger=100;
   int socketTimeout;
   
  +long requestCount=0;
  +
   /* Turning this to true will reduce the latency with about 20%.
  But it requires changes in tomcat to make sure client-requested
  flush() is honored ( on my test, I got 367->433 RPS and
  @@ -130,6 +132,10 @@
   return tp;
   }
   
  +public long getRequestCount() {
  +return requestCount;
  +}
  +
   /** Set the port for the ajp13 channel.
*  To support seemless load balancing and jni, we treat this
*  as the 'base' port - we'll try up until we find one that is not
  @@ -181,23 +187,47 @@
   public void setServerTimeout(int timeout) {
this.serverTimeout = timeout;
   }
  +public int getServerTimeout() {
  +return serverTimeout;
  +}
   
   public void setTcpNoDelay( boolean b ) {
tcpNoDelay=b;
   }
   
  +public boolean getTcpNoDelay() {
  +return tcpNoDelay;
  +}
  +
   public void setSoLinger( int i ) {
linger=i;
   }
   
  +public int getSoLinger() {
  +return linger;
  +}
  +
   public void setSoTimeout( int i ) {
socketTimeout=i;
   }
   
  +public int getSoTimeout() {
  + return socketTimeout;
  +}
  +
   public void setMaxPort( int i ) {
   maxPort=i;
   }
   
  +public int getMaxPort() {
  +return maxPort;
  +}
  +
  +/** At startup we'll look for the first free port in the range.
  +The difference between this port and the beggining of the range
  +is the 'id'.
  +This is usefull for lb cases ( less config ).
  +*/
   public int getInstanceId() {
   return port-startPort;
   }
  @@ -230,6 +260,8 @@
   if( socketTimeout > 0 ) 
   s.setSoTimeout( socketTimeout );
   
  +requestCount++;
  +
   InputStream is=new BufferedInputStream(s.getInputStream());
   OutputStream os;
   if( BUFFER_WRITE )
  @@ -240,6 +272,18 @@
   ep.setNote( osNote, os );
   }
   
  +public void resetCounters() {
  +requestCount=0;
  +}
  +
  +/** Called after you change some fields at runtime using jmx.
  +Experimental for now.
  +*/
  +public void reinit() throws IOException {
  +destroy();
  +init();
  +}
  +
   /**
* @jmx:managed-operation
*/
  @@ -262,7 +306,7 @@
   log.error("Can't find free port " + startPort + " " + maxPort );
   return;
   }
  -log.info("JK: listening on tcp port " + port );
  +log.info("JK2: ajp13 listening on tcp port " + port );
   
   // If this is not the base port and we are the 'main' channleSocket and
   // SHM didn't already set the localId - we'll set the instance id
  @@ -558,8 +602,6 @@
}
return (true);
   }
  -
  -
   }
   
   class SocketAcceptor implements ThreadPoolRunnable {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk build.xml

[costin]

costin  2002/08/09 13:51:35

  Modified:jk   build.xml
  Log:
  Use ${tomcat.util}.jar, don't copy it.
  
  Revision  ChangesPath
  1.46  +3 -3  jakarta-tomcat-connectors/jk/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- build.xml 2 Jul 2002 19:45:49 -   1.45
  +++ build.xml 9 Aug 2002 20:51:35 -   1.46
  @@ -30,6 +30,7 @@
   
   
  +
   
   
   
  @@ -106,16 +107,15 @@
   
   
  -
   
   
  +
   
   
   
   
   
  -
  +
   
   
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java

[costin]

costin  2002/08/09 13:50:38

  Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
  Log:
  Few more fixes and minor enhancements.
  
  Fix recognition of boolean and long, let the caller specify the full name.
  
  Revision  ChangesPath
  1.5   +20 -10
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
  
  Index: DynamicMBeanProxy.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- DynamicMBeanProxy.java9 Aug 2002 17:39:07 -   1.4
  +++ DynamicMBeanProxy.java9 Aug 2002 20:50:38 -   1.5
  @@ -119,19 +119,19 @@
   /** If a name was not provided, generate a name based on the
*  class name and a sequence number.
*/
  -public String generateName(Class realClass) {
  -name=realClass.getName();
  +public static String generateName(Class realClass) {
  +String name=realClass.getName();
   name=name.substring( name.lastIndexOf( ".") + 1 );
   Integer iInt=(Integer)instances.get(name );
  +int seq=0;
   if( iInt!= null ) {
  -int i=iInt.intValue();
  -i++;
  -instances.put( name, new Integer( i ));
  -name=name + "_" + i;
  +seq=iInt.intValue();
  +seq++;
  +instances.put( name, new Integer( seq ));
   } else {
   instances.put( name, new Integer( 0 ));
   }
  -return name;
  +return "name=" + name + " seq=" + seq;
   }
   
   public static void createMBean( Object proxy, String domain, String name ) {
  @@ -140,6 +140,8 @@
   mbean.setReal( proxy );
   if( name!=null ) {
   mbean.setName( name );
  +} else {
  +mbean.setName( generateName( proxy.getClass() ));
   }
   
   mbean.registerMBean( domain );
  @@ -151,7 +153,7 @@
   public void registerMBean( String domain ) {
   try {
   // XXX use aliases, suffix only, proxy.getName(), etc
  -ObjectName oname=new ObjectName( domain + ": name=" +  getName());
  +ObjectName oname=new ObjectName( domain + ": " +  getName());
   
   if(  getMBeanServer().isRegistered( oname )) {
   log.info("Unregistering " + oname );
  @@ -179,8 +181,12 @@
   return ret == String.class ||
   ret == Integer.class ||
   ret == Integer.TYPE ||
  +ret == Long.class ||
  +ret == Long.TYPE ||
   ret == java.io.File.class ||
  -ret == Boolean.class;
  +ret == Boolean.class ||
  +ret == Boolean.TYPE 
  +; 
   }
   
   /** Set the managed object.
  @@ -204,10 +210,14 @@
   if( methods[j].getParameterTypes().length != 0 ) {
   continue;
   }
  -if( ! Modifier.isPublic( methods[j].getModifiers() ) )
  +if( ! Modifier.isPublic( methods[j].getModifiers() ) ) {
  +//log.debug("not public " + methods[j] );
   continue;
  +}
   Class ret=methods[j].getReturnType();
   if( ! supportedType( ret ) ) {
  +if( log.isDebugEnabled() )
  +log.debug("Unsupported " + ret );
   continue;
   }
   name=unCapitalize( name.substring(3));
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util build.xml build.properties.sample

[costin]

costin  2002/08/09 13:49:44

  Modified:util build.xml build.properties.sample
  Log:
  Few minor fixes ( I hope :-)
  
  Revision  ChangesPath
  1.10  +12 -15jakarta-tomcat-connectors/util/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/util/build.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- build.xml 5 Jun 2002 21:12:50 -   1.9
  +++ build.xml 9 Aug 2002 20:49:44 -   1.10
  @@ -1,33 +1,30 @@
   
   
   
  -
   
  +
  +
   
   
   
  -
  +
   
   
   
   
   
  -
  -
  +
  +
   
   
  -
  -
  +
  +
   
   
  -
  -
  -
  -
  +
  +
  +
  +
   
   
   
  @@ -41,7 +38,7 @@
   
   
   
  -
  +
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

RE: [GUMP] cactus-sample-servlet builds

[Costin Manolache]

Vincent Massol wrote:

> Thanks Stefan.
> 
> I though it was an httpclient issue but it tried it locally with the
> latest HttpClient and it ran fine with Tomcat 3.3.1 and Tomcat 4.0.4.
> 
> Thus, I now have the feeling it is a Tomcat 3.3 problem. I just tried
> with yesterday nightly build of Tomcat 3.3 and I get some strange errors
> in my machine (not the same one as you got in your URL below). See
> attached file.
> 
> Has Tomcat 3.3.2 switched to commons-logging ?

Not yet. Jk depends on commons-logging tought.

There is code in CVS that would switch tomcat to commons-logging
( it's a one-line change in Log to set the default ). 

Costin

> 
> Thanks all for your help!
> -Vincent
> 
>> -Original Message-
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
>> Sent: 09 August 2002 07:21
>> To: [EMAIL PROTECTED]
>> Subject: Re: [GUMP] cactus-sample-servlet builds
>> 
>> On Thu, 8 Aug 2002, Larry Isaacs <[EMAIL PROTECTED]> wrote:
>> > Done.
>> 
>> Great.
>> 
>> It seems to have helped a little bit
>> <http://cvs.apache.org/~bodewig/gump/20020809/jakarta-cactus-sample-
>> servlet-12.html>
>> <http://cvs.apache.org/~bodewig/gump/20020809/jakarta-cactus-sample-
>> servlet-13.html>
>> 
>> Thanks
>> 
>> Stefan
>> 
>> --
>> To unsubscribe, e-mail:   <mailto:alexandria-dev-
>> [EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:alexandria-dev-
>> [EMAIL PROTECTED]>




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

Build mod_jk2

[Adrian Almenar]

Were i can find some information on compiling and Using mod_jk2 (I know
its on alpha or beta) with tomcat 4.1.X and apache 2.0.XX ?

Cheers,

-- 
Adrian
GPG Key Fingerprint = 1E78 B604 AA42 B852 1449 0C24 FF6A 1448 A24D 7AF5
Gentoo Linux - Running Linux 2.4.19 with openMosix i686





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

Re: Possible BUG in Send Redirect Tomcat 4.0

[Craig R. McClanahan]

On Fri, 9 Aug 2002, Creighton Kirkendall wrote:

> Date: Fri, 9 Aug 2002 12:23:13 -0400
> From: Creighton Kirkendall <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: 'Tomcat Developers List' <[EMAIL PROTECTED]>
> Subject: Possible BUG in Send Redirect Tomcat 4.0
>
> I think I have found a bug in the sendRedirect.  It is only a problem in
> Tomcat 4 and did not exist in Tomcat 3.x
>
> The following code does work
> response.sendRedirect(response.encodeRedirectURL("/test/test.jsp"));
>
>
> However the following code does not work.
> response.sendRedirect(response.encodeRedirectURL("/test/test.jsp?test=test")
> );
>
>
> It looks like the addition of a Query String causes some problems.  I looked
> at the code and have not found anything that jumps out at me yet.
>

If you think you've found a bug, the best thing to do is report it to the
bug tracking system .  But I can tell
you from experience that a bug report on this will be pretty useless
without being more specific about what "does not work" means.

>
> Creighton Kirkendall

Craig


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

RE: Not sure this is a BUG or a requirement by spec

[Creighton Kirkendall]

Thanks

-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]] 
Sent: Friday, August 09, 2002 2:26 PM
To: Tomcat Developers List
Subject: Re: Not sure this is a BUG or a requirement by spec

This is a bug on your part. The RFC for URI (rfc2396) states that = must 
be encoded as well as some other choice characters.

See section 2.2:
http://www.ietf.org/rfc/rfc2396.txt

Creighton Kirkendall wrote:
> I found where the bug is and I know how to fix it but I am not sure if it
is
> part of the http spec that you can not have "=" in a url parameter value;
> 
> I am trying to parse out a URL that has an embedded url in it, like so:
> src=THIS_IS_JUST_A_TEST&url=/test/test.jsp?test=test&comments=TESTING
> 


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

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

Re: Not sure this is a BUG or a requirement by spec

[Tim Funk]

This is a bug on your part. The RFC for URI (rfc2396) states that = must 
be encoded as well as some other choice characters.

See section 2.2:
http://www.ietf.org/rfc/rfc2396.txt

Creighton Kirkendall wrote:
> I found where the bug is and I know how to fix it but I am not sure if it is
> part of the http spec that you can not have "=" in a url parameter value;
> 
> I am trying to parse out a URL that has an embedded url in it, like so:
> src=THIS_IS_JUST_A_TEST&url=/test/test.jsp?test=test&comments=TESTING
> 


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

RE: [GUMP] cactus-sample-servlet builds

[Vincent Massol]

Thanks Stefan. 

I though it was an httpclient issue but it tried it locally with the
latest HttpClient and it ran fine with Tomcat 3.3.1 and Tomcat 4.0.4.

Thus, I now have the feeling it is a Tomcat 3.3 problem. I just tried
with yesterday nightly build of Tomcat 3.3 and I get some strange errors
in my machine (not the same one as you got in your URL below). See
attached file.

Has Tomcat 3.3.2 switched to commons-logging ?

Thanks all for your help!
-Vincent

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: 09 August 2002 07:21
> To: [EMAIL PROTECTED]
> Subject: Re: [GUMP] cactus-sample-servlet builds
> 
> On Thu, 8 Aug 2002, Larry Isaacs <[EMAIL PROTECTED]> wrote:
> > Done.
> 
> Great.
> 
> It seems to have helped a little bit
> <http://cvs.apache.org/~bodewig/gump/20020809/jakarta-cactus-sample-
> servlet-12.html>
> <http://cvs.apache.org/~bodewig/gump/20020809/jakarta-cactus-sample-
> servlet-13.html>
> 
> Thanks
> 
> Stefan
> 
> --
> To unsubscribe, e-mail:   <mailto:alexandria-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:alexandria-dev-
> [EMAIL PROTECTED]>




cactus.log
Description: Binary data

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

Not sure this is a BUG or a requirement by spec

[Creighton Kirkendall]

I found where the bug is and I know how to fix it but I am not sure if it is
part of the http spec that you can not have "=" in a url parameter value;

I am trying to parse out a URL that has an embedded url in it, like so:
src=THIS_IS_JUST_A_TEST&url=/test/test.jsp?test=test&comments=TESTING

The problem comes when org.apache.catalina.util.RequestUtil. parseParameters
is called and it tries to parse the url.  Since it uses a case statement
that checks every character for a "=" and then assigns the left to a Key and
right to a value.  This causes a problem because it ignores the "url=" and
places a key in the map of "=/test/test.jsp?test" and a value of "test".
Should it not place "url" as the key and "/test/test.jsp?test=test" as the
value?  Below is a class that illustrates the problem. To fix this we need
to modify the case so that it knows when it state is in a key and when it is
in a value.



import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
import org.apache.catalina.util.ParameterMap;
import org.apache.catalina.util.RequestUtil;


public class parseParamsTest {

  /**
   * Initialize global variables
   */

  /**
   * Process the HTTP Get request
   */
public static void main(String[] args) {
  try{
String
query="src=THIS_IS_JUST_A_TEST&url=/test/test.jsp?test=test&comments=TESTING
";
/* the above query should output the following Key values pairs
  src=HIS_IS_JUST_A_TEST
  url=/test/test.jsp?test=test
  comments=TESTING
*/

ParameterMap tmp=new ParameterMap();
RequestUtil.parseParameters(tmp,query,"ISO-8859-1");
Set s=tmp.keySet();
Iterator it=s.iterator();
while(it.hasNext()){
  String key=(String)it.next();
  String[] values=(String[])tmp.get(key);
  for(int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[costin]

costin  2002/08/09 10:45:50

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  Few cosmetic fixes. Remove old code ( uriEnv can't be null ).
  
  The uriEnv==null case was used to support SetHandler directive -
  which only sets jakarta-servlet handler but doesn't set any module-specific
  field
  We may add this later - for now using JkUriSet in a  works fine.
  
  Revision  ChangesPath
  1.47  +8 -19 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- mod_jk2.c 24 Jul 2002 00:44:20 -  1.46
  +++ mod_jk2.c 9 Aug 2002 17:45:49 -   1.47
  @@ -524,7 +524,6 @@
   jk_endpoint_t *end = NULL;
   jk_uriEnv_t *uriEnv;
   jk_env_t *env;
  -jk_workerEnv_t *workerEnv;
   
   jk_ws_service_t *s=NULL;
   jk_pool_t *rPool=NULL;
  @@ -541,8 +540,6 @@
   return HTTP_INTERNAL_SERVER_ERROR;
   }
   
  -workerEnv = uriEnv->workerEnv;
  -
   /* Get an env instance */
   env = workerEnv->globalEnv->getEnv( workerEnv->globalEnv );
   
  @@ -554,22 +551,14 @@
   return rc;
   }
   
  -if( uriEnv == NULL ) {
  -/* SetHandler case - per_dir config should have the worker*/
  -worker =  workerEnv->defaultWorker;
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  -  "mod_jk.handler() Default worker for %s %s\n",
  -  r->uri, worker->mbean->name); 
  -} else {
  -worker=uriEnv->worker;
  +worker=uriEnv->worker;
   
  -if( worker==NULL && uriEnv->workerName != NULL ) {
  -worker=env->getByName( env, uriEnv->workerName);
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  -  "mod_jk.handler() finding worker for %#lx %#lx %s\n",
  -  worker, uriEnv, uriEnv->workerName);
  -uriEnv->worker=worker;
  -}
  +if( worker==NULL && uriEnv->workerName != NULL ) {
  +worker=env->getByName( env, uriEnv->workerName);
  +env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +  "mod_jk.handler() finding worker for %#lx %#lx %s\n",
  +  worker, uriEnv, uriEnv->workerName);
  +uriEnv->worker=worker;
   }
   
   if(worker==NULL || worker->mbean == NULL || worker->mbean->localName==NULL ) {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java

[costin]

costin  2002/08/09 10:42:44

  Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
  Log:
  Move start to the right place.
  
  Now the ajp13 port will be opened at the same time with the http port,
  i.e. at server startup.
  
  Revision  ChangesPath
  1.26  +8 -4  
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
  
  Index: JkCoyoteHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- JkCoyoteHandler.java  2 Jul 2002 16:57:30 -   1.25
  +++ JkCoyoteHandler.java  9 Aug 2002 17:42:44 -   1.26
  @@ -63,7 +63,6 @@
   import java.net.*;
   import java.util.*;
   
  -import org.apache.jk.*;
   import org.apache.jk.core.*;
   import org.apache.jk.common.*;
   
  @@ -147,7 +146,6 @@
   // jkMain.setJkHome() XXX;
   
   jkMain.init();
  -jkMain.start();
   
   headersMsgNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, "headerMsg" );
   utfC2bNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, "utfC2B" );
  @@ -162,6 +160,11 @@
   }
   
   public void start() {
  +try {
  +jkMain.start();
  +} catch( Exception ex ) {
  +ex.printStackTrace();
  +}
   }
   
   public void destroy() {
  @@ -334,7 +337,8 @@
   org.apache.coyote.Response res=(org.apache.coyote.Response)param;
   MsgContext ep=(MsgContext)res.getNote( epNote );
   if( ep.getStatus()== JK_STATUS_CLOSED ) {
  -// Double close - it may happen with forward
  +// Double close - it may happen with forward 
  +if( log.isDebugEnabled() ) log.debug("Double CLOSE - forward ? 
" + res.getRequest().requestURI() );
   return;
   }

  @@ -361,7 +365,7 @@
   
   } else if( actionCode==ActionCode.ACTION_REQ_HOST_ATTRIBUTE ) {
   
  -} else if( actionCode==ActionCode.ACTION_POST_REQUEST ) {
  +// } else if( actionCode==ActionCode.ACTION_POST_REQUEST ) {
   
   } else if( actionCode==ActionCode.ACTION_ACK ) {
   if( log.isDebugEnabled() )
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java

[costin]

costin  2002/08/09 10:39:07

  Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
  Log:
  Added 'createMBean( Object, domain, name )'.
  Any component that wants to be visible in JMX needs one line
  in the constructor:
  
org.apache.tomcat.util.mx.DynamicMBeanProxy.createMBean( this, "domain", "name" );
  
  ( you can do that for other components as well ).
  
  I'll eventually refactor this into 2 classes and move to modeler,
  with one class beeing independent of JMX.
  
  Revision  ChangesPath
  1.4   +29 -2 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
  
  Index: DynamicMBeanProxy.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DynamicMBeanProxy.java2 Jul 2002 19:56:24 -   1.3
  +++ DynamicMBeanProxy.java9 Aug 2002 17:39:07 -   1.4
  @@ -112,7 +112,15 @@
   
   if( real==null ) return null;
   
  -name=real.getClass().getName();
  +name=generateName(real.getClass());
  +return name;
  +}
  +
  +/** If a name was not provided, generate a name based on the
  + *  class name and a sequence number.
  + */
  +public String generateName(Class realClass) {
  +name=realClass.getName();
   name=name.substring( name.lastIndexOf( ".") + 1 );
   Integer iInt=(Integer)instances.get(name );
   if( iInt!= null ) {
  @@ -125,12 +133,30 @@
   }
   return name;
   }
  +
  +public static void createMBean( Object proxy, String domain, String name ) {
  +try {
  +DynamicMBeanProxy mbean=new DynamicMBeanProxy();
  +mbean.setReal( proxy );
  +if( name!=null ) {
  +mbean.setName( name );
  +}
  +
  +mbean.registerMBean( domain );
  +} catch( Throwable t ) {
  +log.error( "Error creating mbean ", t );
  +}
  +}
   
   public void registerMBean( String domain ) {
   try {
   // XXX use aliases, suffix only, proxy.getName(), etc
   ObjectName oname=new ObjectName( domain + ": name=" +  getName());
  -
  +
  +if(  getMBeanServer().isRegistered( oname )) {
  +log.info("Unregistering " + oname );
  +getMBeanServer().unregisterMBean( oname );
  +}
   getMBeanServer().registerMBean( this, oname );
   } catch( Throwable t ) {
   log.error( "Error creating mbean ", t );
  @@ -298,6 +324,7 @@
   throws AttributeNotFoundException, InvalidAttributeValueException, 
MBeanException, ReflectionException
   {
   if( methods==null ) init();
  +// XXX Send notification !!!
   Method m=(Method)setAttMap.get( attribute.getName() );
   if( m==null ) throw new AttributeNotFoundException(attribute.getName());
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/conf jk2.properties

[costin]

costin  2002/08/09 10:36:17

  Modified:jk/conf  jk2.properties
  Log:
  Comment out the shm and apr options. That will prevent loading - and
  the associated warnings.
  
  Revision  ChangesPath
  1.9   +3 -3  jakarta-tomcat-connectors/jk/conf/jk2.properties
  
  Index: jk2.properties
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/jk2.properties,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jk2.properties22 May 2002 23:49:18 -  1.8
  +++ jk2.properties9 Aug 2002 17:36:17 -   1.9
  @@ -6,10 +6,10 @@
   ## DOCUMENTATION OF THE FORMAT IN JkMain javadoc.
   
   # Override the default port for the socketChannel
  -channelSocket.port=8019
  +# channelSocket.port=8019
   # Default: 
   # channelUnix.file=${jkHome}/work/jk2.socket
   # Just to check if the the config  is working
  -shm.file=${jkHome}/work/jk2.shm
  +# shm.file=${jkHome}/work/jk2.shm
   
  -apr.jniModeSo=/opt/apache2/modules/mod_jk2.so
  +# apr.jniModeSo=/opt/apache2/modules/mod_jk2.so
  
  
  

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

DO NOT REPLY [Bug 11596] New: - cookies not working in netscape 4.76 on tomcat 4.0.4

[bugzilla]

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

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

cookies not working in netscape 4.76 on tomcat 4.0.4

   Summary: cookies not working in netscape 4.76 on tomcat 4.0.4
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a site that initiates a cookie which works fine, however after beginning 
a new session all I can do is access the cookie. I can't add to it, kill it or 
insert a new one in place of it and have the new cookie be persisted. It acts as 
if it is a session variable. I have it running with previous versions of tomcat. 
Any ideas on this.

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

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

[horwat]

horwat  2002/08/09 10:20:48

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  RequestListenerValve should be skipped when persisting state.
  
  Revision  ChangesPath
  1.3   +5 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- StandardServer.java   2 Aug 2002 01:37:43 -   1.2
  +++ StandardServer.java   9 Aug 2002 17:20:48 -   1.3
  @@ -197,6 +197,7 @@
   "org.apache.catalina.valves.CertificatesValve",
   "org.apache.catalina.valves.ErrorDispatcherValve",
   "org.apache.catalina.valves.ErrorReportValve",
  +"org.apache.catalina.valves.RequestListenerValve",
   };
   
   
  
  
  

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

RE: Possible BUG in Send Redirect Tomcat 4.0

[Creighton Kirkendall]

Ignore the previous message it looks like it is somewhere else.

-Original Message-
From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]] 
Sent: Friday, August 09, 2002 12:23 PM
To: 'Tomcat Developers List'
Subject: Possible BUG in Send Redirect Tomcat 4.0

I think I have found a bug in the sendRedirect.  It is only a problem in
Tomcat 4 and did not exist in Tomcat 3.x

The following code does work 
response.sendRedirect(response.encodeRedirectURL("/test/test.jsp"));


However the following code does not work.
response.sendRedirect(response.encodeRedirectURL("/test/test.jsp?test=test")
);


It looks like the addition of a Query String causes some problems.  I looked
at the code and have not found anything that jumps out at me yet.


Creighton Kirkendall


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

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteRequest.java

[horwat]

horwat  2002/08/09 09:58:43

  Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteRequest.java
  Log:
  Synchronization is unnecessary since requests are per-thread.
  
  Submitted by: Bill Barker
  
  Revision  ChangesPath
  1.3   +25 -23
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CoyoteRequest.java9 Aug 2002 02:10:10 -   1.2
  +++ CoyoteRequest.java9 Aug 2002 16:58:43 -   1.3
  @@ -1151,17 +1151,17 @@
   boolean found = false;
   
   // Remove the specified attribute
  -synchronized (attributes) {
  -// Check for read only attribute
  -   if (readOnlyAttributes.containsKey(name))
  -return;
  -found = attributes.containsKey(name);
  -if (found) {
  -value = attributes.get(name);
  -attributes.remove(name);
  -} else {
  -return;
  -}
  +// Check for read only attribute
  +// requests are per thread so synchronization unnecessary
  +if (readOnlyAttributes.containsKey(name)) {
  +return;
  +}
  +found = attributes.containsKey(name);
  +if (found) {
  +value = attributes.get(name);
  +attributes.remove(name);
  +} else {
  +return;
   }
   
   // Notify interested application event listeners
  @@ -1209,15 +1209,17 @@
   boolean replaced = false;
   
   // Add or replace the specified attribute
  -synchronized (attributes) {
  -// Check for read only attribute
  -if (readOnlyAttributes.containsKey(name))
  -return;
  -oldValue = attributes.get(name);
  -if (oldValue != null)
  -replaced = true;
  -attributes.put(name, value);
  +// Check for read only attribute
  +// requests are per thread so synchronization unnecessary
  +if (readOnlyAttributes.containsKey(name)) {
  +return;
  +}
  +oldValue = attributes.get(name);
  +if (oldValue != null) {
  +replaced = true;
   }
  +
  +attributes.put(name, value);
   
   // Notify interested application event listeners
   Object listeners[] = context.getApplicationListeners();
  
  
  

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

Few additions to CatalinaService

[Costin Manolache]

I'm not sure if Remy was -1 or not ( well, technically you can't 
-1 until you see the code :-). 

I would like to _add_ few methods to CatalinaService ( with no change
to existing ones ). Basically setters and an execute(), to allow:

 
  

It can be done in a separate class, but we have already far too 
many.

I would also add some description of those methods in the 
mbean-descriptors.xml file ( or just add a call to DynamicMBean ).


Costin



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

DO NOT REPLY [Bug 11592] New: - Starting apache sever

[bugzilla]

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

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

Starting apache sever

   Summary: Starting apache sever
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have configured and made the webapp module in several different ways but no 
matter how i do it the end result when i try to load the module from httpd.conf 
is this error message "httpd fialed to start. The error was: "Syntax error on 
line 280 of /etc/httpd/conf/httpd.conf (line 280 reads LoadModule 
webapp_modulemodules/mod_webapp.so). Cannot load [dir]/mod_webapp.so into 
server: [dir]/mod_webapp.so: undefined symbol: apr_pool_cleanup_null [FAILED]".

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

Possible BUG in Send Redirect Tomcat 4.0

[Creighton Kirkendall]

I think I have found a bug in the sendRedirect.  It is only a problem in
Tomcat 4 and did not exist in Tomcat 3.x

The following code does work 
response.sendRedirect(response.encodeRedirectURL("/test/test.jsp"));


However the following code does not work.
response.sendRedirect(response.encodeRedirectURL("/test/test.jsp?test=test")
);


It looks like the addition of a Query String causes some problems.  I looked
at the code and have not found anything that jumps out at me yet.


Creighton Kirkendall


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

cvs commit: jakarta-tomcat-connectors/coyote build.xml

[patrickl]

patrickl2002/08/09 09:24:22

  Modified:coyote   build.xml
  Log:
  A change made last night to coyote/build.xml stopped the tomcat5 directory of coyote 
from building.  This change fixes this.  (Thanks to Ryan Lubke for pointing this out.)
  Submitted by: Bob Herrmann ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.13  +2 -2  jakarta-tomcat-connectors/coyote/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- build.xml 9 Aug 2002 12:55:01 -   1.12
  +++ build.xml 9 Aug 2002 16:24:22 -   1.13
  @@ -241,7 +241,7 @@
 
   
 
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java

[patrickl]

patrickl2002/08/09 09:23:25

  Modified:coyote/src/java/org/apache/coyote Response.java
   coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java
  Log:
  In the Servlet 2.4 spec section 5.4 on i18n, the deployment descriptor gets new 
stuff for mapping locale to character encoding.
  
  Revision  ChangesPath
  1.13  +4 -3  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
  
  Index: Response.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Response.java 1 Aug 2002 17:20:36 -   1.12
  +++ Response.java 9 Aug 2002 16:23:25 -   1.13
  @@ -455,8 +455,6 @@
   if (isCommitted())
   return;
   
  -characterEncoding = charset;
  -
   String type = this.contentType;
   int start = type.indexOf("charset=");
   if ( start != -1 ) {
  @@ -468,8 +466,11 @@
   type = type.substring(0,start+8)
   +charset;
   this.contentType = type;
  -
  +} else {
  +type += "charset=" + charset;
   }
  +setContentType( type );
  +
   }
   
   public String getCharacterEncoding() {
  
  
  
  1.3   +10 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CoyoteResponse.java   8 Aug 2002 04:08:41 -   1.2
  +++ CoyoteResponse.java   9 Aug 2002 16:23:25 -   1.3
  @@ -753,6 +753,12 @@
   
   coyoteResponse.setLocale(locale);
   
  +CharsetMapper cm = context.getCharsetMapper();
  +String charset = cm.getCharset( locale );
  +
  +if ( charset != null )
  +setCharacterEncoding( charset);
  +
   }
   
   
  
  
  

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

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

[patrickl]

patrickl2002/08/09 09:22:36

  Modified:catalina/src/share/org/apache/catalina Context.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java
   catalina/src/share/org/apache/catalina/startup
WebRuleSet.java
   catalina/src/share/org/apache/catalina/util
CharsetMapper.java
  Log:
  In the Servlet 2.4 spec section 5.4 on i18n, the deployment descriptor gets new 
stuff for mapping locale to character encoding.
  Submitted by:  Bob Herrmann ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.3   +13 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Context.java
  
  Index: Context.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Context.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Context.java  2 Aug 2002 01:37:42 -   1.2
  +++ Context.java  9 Aug 2002 16:22:36 -   1.3
  @@ -481,6 +481,15 @@
   
   
   /**
  + * Add a Locale Encoding Mapping (see Sec 5.4 of Servlet spec 2.4)
  + *
  + * @param locale locale to map an encoding for
  + * @param encoding encoding to be used for a give locale
  + */
  +public void addLocaleEncodingMappingParameter(String locale, String encoding);
  +
  +
  +/**
* Add a local EJB resource reference for this web application.
*
* @param ejb New local EJB resource reference
  
  
  
  1.4   +15 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- StandardContext.java  9 Aug 2002 02:07:12 -   1.3
  +++ StandardContext.java  9 Aug 2002 16:22:36 -   1.4
  @@ -1512,6 +1512,17 @@
   
   
   /**
  + * Add a Locale Encoding Mapping (see Sec 5.4 of Servlet spec 2.4)
  + *
  + * @param locale locale to map an encoding for
  + * @param encoding encoding to be used for a give locale
  + */
  +public void addLocaleEncodingMappingParameter(String locale, String encoding){
  +getCharsetMapper().addCharsetMappingFromDeploymentDescriptor(locale, 
encoding);
  +}
  +
  +
  +/**
* Add a local EJB resource reference for this web application.
*
* @param ejb New EJB resource reference
  
  
  
  1.4   +9 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java
  
  Index: WebRuleSet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- WebRuleSet.java   8 Aug 2002 18:33:19 -   1.3
  +++ WebRuleSet.java   9 Aug 2002 16:22:36 -   1.4
  @@ -385,6 +385,11 @@
   digester.addCallMethod(prefix + "web-app/welcome-file-list/welcome-file",
  "addWelcomeFile", 0);
   
  +digester.addCallMethod(prefix + 
"web-app/locale-encoding-mapping-list/locale-encoding-mapping",
  +  "addLocaleEncodingMappingParameter", 2);
  +digester.addCallParam(prefix + 
"web-app/locale-encoding-mapping-list/locale-encoding-mapping/locale", 0);
  +digester.addCallParam(prefix + 
"web-app/locale-encoding-mapping-list/locale-encoding-mapping/encoding", 1);
  +
   }
   
   
  
  
  
  1.2   +14 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
  
  Index: CharsetMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CharsetMapper.java18 Jul 2002 16:47:45 -  1.1
  +++ CharsetMapper.java9 Aug 2002 16:22:36 -   1.2
  @@ -171,5 +171,18 @@
   
   }
   
  +/**
  + * The deployment descriptor can have a
  + * locale-encoding-mapping-list element which describes the
  + * webapp's desired mapping from locale to charset.  This method
  + * gets called when processing the web.xml file for a context
  + *
  + * @param locale The locale for a character set
  + * @param charset The charset to be associated with the locale
  + */
  +public void addCharsetMappingFromDeploymentDescriptor(String locale,String 
charset) {
  +map.put( loc

Re: [5.0] Build notes

[Bob Herrmann]

Yea, I liked your script, this one builds Tomcat 5.

BUILDING.TXT could almost just say "All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)"

This should be cross platform (haven't tested it on Win32.)

Cheers,
-bob














 
 

























On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
> On August 6, 2002 01:01 pm, you wrote:
> > The main thing missing is a target which sets up the CVS repositories,
> > so it's quite close to what we have now. Problem is, I'm not too happy
> > at the idea of doing that automatically.
> 
> Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
> it's well documented what it's doing, people should be OK with it.
> 
> Ian
> 
> 
> 
>   
> 
>   
>   
>  value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
> 
>   
>   
>
>   
> 
>   
> 
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>  cvsRoot="${cvs.root}"
>   dest="${apache.dir}"
>   />
>   
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



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

[5][PATCH] tomcat5.coyote not getting compiled

[Bob Herrmann]

A change made last night to coyote/build.xml stopped the tomcat5
directory of coyote from building.  This change fixes this.  (Thanks to
Ryan Lubke for pointing this out.)

Cheers,
-bob



Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/coyote/build.xml,v
retrieving revision 1.12
diff -u -r1.12 build.xml
--- build.xml	9 Aug 2002 12:55:01 -	1.12
+++ build.xml	9 Aug 2002 15:46:59 -
@@ -241,7 +241,7 @@
   
 
   
 

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

RE: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

[Mladen Turk]

> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache
> 
> I thought about this few times - it's a good idea but a bit 
> scary ( the build process )

The easiest would be if the guys from Apache 2 move the regex to the
apr-util (I already make the question about that on the apr-dev).
Apache 2 builds should be relatively easy to implement since we have the
pcrelib already there. For the rest of the servers (IIS) we have the
.dsp and all that is needed is to include that in the module build.

> and not sure if a general regexp will work as well on the simple
patterns we have.

Well everything is precompiled, so the performance shouldn't be an issue
here.
 
> 
> I'm +1 if you can do it first in an 'optional' way - 
> like a separate module that can be excluded and will be
> used based on some option. It may need some hooks.
>

I was planning to do that any way since this has lot of implications to
the existing mappings, moving the new code to the jk_uriMapX.c and
keeping function naming as is.

 
> If you want to start on this, I would propose we branch the 
> code for a stable 1.0 release.
> 
> My current thinking is to use 4.1.9 ( or whatever is the stable
> release) as a tag for jk1.2 'stable' and jk2 'beta'.
> 

Ok. That would be fine with me.


MT.


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

DO NOT REPLY [Bug 11573] - Can't run or compile JSP's

[bugzilla]

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

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

Can't run or compile JSP's

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-08-09 15:18 ---
Well, I figured out the problem. Forte for Java 4 has got some serious issues 
with Tomcat integration.

Forte comes with Tomcat 4.0.1 pre-installed and NOT removable per the docs 
anyway... IT does say, however, that you can add other servlet containers 
including other versions of Tomcat.

The problem was that to "integrate" it with the IDE you have to allow Forte to 
edit some Tomcat config files. In this case it replaced the reference to 
Tomcat's Jasper in web.xml with its own package, which is messed up badly... it 
craps out with a ton of exceptions. Once I restored the Jasper directive, bing! 
Instant JSP pages!

The pre-installed version that comes with Forte also cannot function properly I 
have discovered. It can't even load the examples.

I am very sorry if I wasted anyone's time over this. I spent a lot of time 
trying to indentify the problem, and because of my newbie-ness I gave up to 
quickly in frustration. Again, I apologize.

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

Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

[Costin Manolache]

I thought about this few times - it's a good idea but a bit 
scary ( the build process ), and not sure if a general regexp
will work as well on the simple patterns we have.

On the other side most regexp impl. use finite machines and
many optimizations - so they may be much faster.

I'm +1 if you can do it first in an 'optional' way - 
like a separate module that can be excluded and will be
used based on some option. It may need some hooks.

If you want to start on this, I would propose we branch the 
code for a stable 1.0 release.

My current thinking is to use 4.1.9 ( or whatever is the stable
release) as a tag for jk1.2 'stable' and jk2 'beta'.

Costin

 

On Fri, 09 Aug 2002 04:07:27 -0700, Mladen Turk wrote:

> Hi,
> 
> Remember the last month advanced URI space resolution I proposed?
> 
> Well, I've been working on that for a week or so, and found myself doing
> things that are more or less regular expression matching of request uri.
> Even existing uri_map code has a trace of that (matching star for
> example), so IMO (since we are matching things) we could use the regex
> code as a general uri->file space matching solution. That way the users
> will be able to use the same syntax as for the  or
> mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE
> cases.
> 
> The major drawback of that is that we'll need the pcre library, either
> one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by
> Henry Spencer). Since the same should be used with the IIS and other
> platforms, I suggest that we use the one from Apache 2.0.
> 
> Using pcre will introduce the need for build process changes (only 2.0
> can use the proposed pcre from its own build) and we'll need the
> pcre.lib.
> 
> Thoughts?
> 
> MT.



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

Re: [POLL] Configuration API of tomcat5

[Costin Manolache]

On Fri, 09 Aug 2002 02:24:32 -0700, Remy Maucherat wrote:

>> 1. JMX as low-level configuration API. The question is - should we
>> follow the path of JBoss and make everything that is configurable an
>> MBean, and base the entire architecture on JMX ? The benefits: -
>> standard API
>> - reasonably clean
>> - easy to integrate with other apps using JMX
>> 
>> Possible problems:
>> - may affect performance ( lots of introspection - jboss does a lot of
>> tricks in their jmx impl. )
>> - we still don't have the test suite for jmx - so licence issues are
>> still there ( and we don't know if mx4j would pass it ) - we'll be very
>> dependent on JMX - with little control over implementation. - again,
>> tomcat won't work without jmx.
> 
> BTW, I don't see performance being much worse than the current solution,
> which is already very slow, and is also completely based on
> introspection.

It's much more than the introspection we do, plus tons of Strings 
( the ObjectName ), tons of other objects.

But it's not the worse option - JBoss proved that JMX can be made
efficient and that the model works well. 


>> One possible ( still standard ) API for the wrapper is JNDI. If we
>> register all the 'interesting' objects in the jndi we can easily 'wrap'
>> them for jmx. The APIs are very similar, the code is easy and most
>> people are supposed to be familiar with the API. There are other
>> choices as well.
>> 
>> We already depend on JNDI - so no extra deps here, and it'll probably
>> be easier to make it work with ldap or other backends.
> 
> Maybe.

We should discuss this one a bit more - it basically means a DirContext
that doubles as MBean. ( JBoss has a ContextMBean that can be used to 
view the jndi objects from the admin interface, that's slightly different ).
If we do that all config information will be accessible in both ways.

The APIs are very similar, except the goal of JNDI is more 'storage' 
( not for java:env, but LDAP and all other ), JMX is more 'runtime data'.
And JNDI is more focused on the hierarchy of the DN, while JMX leaves it
almost unspecified as semantic but is strict on syntax.



>> 3. Small config API ( with JMX hooks ). That's what I started in
>> util.config - just minimal objectName/attributes/attriubte change
>> notifications, no extra overhead.
>> That would probably be cleaner and smaller, but it's yet-another-api.
> 
> That's up to you. If you think it's useful to use a middle man between
> JMX and the Tomcat code, then I think it's good.
> 
> An advantage of that one may be that the (needed) refactoring of the
> config save may actually be clean, and that it abstracts the
> configuration storage (good).

Well, I can't start much code until I know what people want.
And that involves API in the first place, and data format ( for the
default XML file ). But API is the most important.

It seems either everyone is in vacation or too busy - and this is 
too important an issue to do alone. 


>> 4. Just keep the current API and implementation, with a jmx layer on
>> top. The listener provides access to the objects and allows it to
>> transparently register them with JMX. We rewrite the config read to
>> keep the information in memory and get all the changes made by user,
>> then save. We could use DOM or something similar and preserve even the
>> comments ( if XML backend is used ).
>> 
>> The key difference is in what we use as a low-level API to 'assemble'
>> the components. First 3 choices give more decoupling, the third is the
>> easiest to implement ( almost nothing to change ).
> 
> The 3rd one looks the most interesting. It provides a good level of
> abstraction while being independent from JMX.
> 
> I'd be willing to help implement it.

That would be great - but first I think we need to find more help in
designing it, at least more feedback on which direction to go.

I love java and OO programming, but sometimes I have a feeling it uses
too many ( and too bloated ) APIs and interfaces, and I don't want to
agravate this :-) That's why I slightly perfer one of the first 2 aproaches. 


Costin



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

cvs commit: jakarta-tomcat-connectors/coyote build.xml

[larryi]

larryi  2002/08/09 05:55:02

  Modified:coyote   build.xml
  Log:
  Exclude tomcat5 from "compile.shared" too.
  
  Revision  ChangesPath
  1.12  +2 -1  jakarta-tomcat-connectors/coyote/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- build.xml 4 Aug 2002 19:39:49 -   1.11
  +++ build.xml 9 Aug 2002 12:55:01 -   1.12
  @@ -185,6 +185,7 @@
  deprecation="${compile.deprecation}"
 optimize="${compile.optimize}">
 
  +  
 
 
   
  
  
  

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

Re: [4.1.9] Fix for major bugs

[Glenn Nielsen]

Remy Maucherat wrote:
> A few major bugs were fixed in CVS (two tricky bugs in Coyote HTTP/1.1, 
> one in Jasper, and possibly one in the Catalina CL - bug 11307). I plan 
> to release a 4.1.9 milestone when 11307 is confirmed to be fixed.
> 
> We may then consider 4.1.9 as a candidate for a stable release, as there 
> are no real showstopper problems left I can think of (and huge 
> improvements over 4.0.x).
> 
> One of the issues left is that DBCP is not stable yet. Could this be 
> addressed anytime soon ?
> 

I am using DBCP in production and it seems stable.  Is the issue that
there hasn't been a release of DBCP?  If so, we will need to propose
a release of DBCP on commons-dev.

Also the docs need updating.

I just checked the docs at:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples-howto.html

and some things are out of date, plus they don't mention some of the new features in
DBCP such as recovering abandoned db connections.

Regards,

Glenn


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




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

uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

[Mladen Turk]

Hi,

Remember the last month advanced URI space resolution I proposed?

Well, I've been working on that for a week or so, and found myself doing
things that are more or less regular expression matching of request uri.
Even existing uri_map code has a trace of that (matching star for
example), so IMO (since we are matching things) we could use the regex
code as a general uri->file space matching solution. That way the users
will be able to use the same syntax as for the  or
mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE
cases.

The major drawback of that is that we'll need the pcre library, either
one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by
Henry Spencer). Since the same should be used with the IIS and other
platforms, I suggest that we use the one from Apache 2.0.

Using pcre will introduce the need for build process changes (only 2.0
can use the proposed pcre from its own build) and we'll need the
pcre.lib.

Thoughts?

MT.


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

[GUMP] Build Failure - jakarta-tomcat-coyote

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

init:
 [echo]  Coyote 1.0-dev 

prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/classes
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/conf
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/docs
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/docs/api
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/lib
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/tests

static:
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/conf

report-tc5:

report-tc4:
 [echo] Tomcat4 detected 

report-tc33:
 [echo] Tomcat3.3 detected 

report:

compile.shared:
[javac] Compiling 22 source files to 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/build/classes
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:94:
 cannot resolve symbol
[javac] symbol  : class ServletRequestEvent  
[javac] location: package servlet
[javac] import javax.servlet.ServletRequestEvent;
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:95:
 cannot resolve symbol
[javac] symbol  : class ServletRequestListener  
[javac] location: package servlet
[javac] import javax.servlet.ServletRequestListener;
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:96:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeEvent  
[javac] location: package servlet
[javac] import javax.servlet.ServletRequestAttributeEvent;
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:97:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeListener  
[javac] location: package servlet
[javac] import javax.servlet.ServletRequestAttributeListener;
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1171:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeEvent  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac] ServletRequestAttributeEvent event =
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1172:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeEvent  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac]   new ServletRequestAttributeEvent(context.getServletContext(),
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1175:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeListener  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac] if (!(listeners[i] instanceof ServletRequestAttributeListener))
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1177:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeListener  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac] ServletRequestAttributeListener listener =
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1178:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeListener  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac] (ServletRequestAttributeListener) listeners[i];
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequest.java:1226:
 cannot resolve symbol
[javac] symbol  : class ServletRequestAttributeEvent  
[javac] location: class org.apache.coyote.tomcat5.CoyoteRequest
[javac] ServletRequestAttributeEvent event = null;
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-tomcat-connectors/coyote/src/java/org/a

DO NOT REPLY [Bug 11489] - Scanning JAR files in WEB-INF/lib without temp 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=11489

Scanning JAR files in WEB-INF/lib without temp directory

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2002-08-09 10:13 ---
The default installation works fine.

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

DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader

[bugzilla]

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

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

Deadlock in ClassLoader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-09 10:12 ---
This is likely fixed in CVS. Please confirm. The fix will be in 4.1.9.

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

DO NOT REPLY [Bug 11586] New: - HttpSessionBindingEvent.getValue() returns null for not null value

[bugzilla]

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

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

HttpSessionBindingEvent.getValue() returns null for not null value

   Summary: HttpSessionBindingEvent.getValue() returns null for not
null value
   Product: Tomcat 4
   Version: 4.0 Beta 4
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


HttpSessionBindingEvent.getValue() fired by a 
HttpSessionBindingListener.valueUnbound() returns null even if I know it was 
not a null value.

Regards
Alessandro Scotti

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

[4.1.9] Fix for major bugs

[Remy Maucherat]

A few major bugs were fixed in CVS (two tricky bugs in Coyote HTTP/1.1, 
one in Jasper, and possibly one in the Catalina CL - bug 11307). I plan 
to release a 4.1.9 milestone when 11307 is confirmed to be fixed.

We may then consider 4.1.9 as a candidate for a stable release, as there 
are no real showstopper problems left I can think of (and huge 
improvements over 4.0.x).

One of the issues left is that DBCP is not stable yet. Could this be 
addressed anytime soon ?

Remy


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

DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader

[bugzilla]

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

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

Deadlock in ClassLoader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-08-09 10:03 ---
Ok, thanks for the explanation. I think I understand the issue a bit better now.

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

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

[remm]

remm2002/08/09 03:01:48

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - Attempt to fix 11307. Please test, there could be regressions and thread safety
problems, and I have no way to properly test this.
  - Sync on the CL itself instead of the ResourceEntry, which caused problems
because of locking which could occur in the superclass.
  - Thanks to Scott Ganyo  for the report and the
explanation.
  
  Revision  ChangesPath
  1.45  +16 -14
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- WebappClassLoader.java6 Aug 2002 00:16:59 -   1.44
  +++ WebappClassLoader.java9 Aug 2002 10:01:48 -   1.45
  @@ -1654,18 +1654,20 @@
   
   }
   
  -synchronized (entry) {
  -// Since all threads use the same ResourceEntry instance, it is
  -// the one which will contain the class
  -if (entry.loadedClass == null) {
  -clazz = defineClass(name, entry.binaryContent, 0,
  -entry.binaryContent.length, codeSource);
  -entry.loadedClass = clazz;
  -} else {
  -clazz = entry.loadedClass;
  +if (entry.loadedClass == null) {
  +synchronized (this) {
  +if (entry.loadedClass == null) {
  +clazz = defineClass(name, entry.binaryContent, 0,
  +entry.binaryContent.length, 
  +codeSource);
  +entry.loadedClass = clazz;
  +} else {
  +clazz = entry.loadedClass;
  +}
   }
  +} else {
  +clazz = entry.loadedClass;
   }
  -
   
   return clazz;
   
  
  
  

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

DO NOT REPLY [Bug 11584] New: - Configuration files owned by tomcat3 not root

[bugzilla]

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

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

Configuration files owned by tomcat3 not root

   Summary: Configuration files owned by tomcat3 not root
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


tomcat 3.3.1 when installed from rpm runs as user tomcat3 and has it's
configuration files rewritable by this user.

[root@hovercraft pete]# ls -l /etc/tomcat3/conf/tomcat3.conf
-rw-r--r--1 tomcat3  tomcat3   866 Apr 30 16:28
/etc/tomcat3/conf/tomcat3.conf


However, this file allows you to specify the user tomcat runs as - i.e. the
tomcat3 user can rewrite his user directive to be root and then wait for a
restart  allowing him to escalate his user level to root. I think the
configuration files should be owned by root, not tomcat3.

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

Re: [POLL] Configuration API of tomcat5

[Remy Maucherat]

Costin Manolache wrote:
> Few questions:
> 
> 1. JMX as low-level configuration API. 
> The question is - should we follow the path of JBoss and make everything 
> that is configurable an MBean, and base the entire architecture on JMX ? 
> The benefits:
> - standard API
> - reasonably clean
> - easy to integrate with other apps using JMX
> 
> Possible problems:
> - may affect performance ( lots of introspection - jboss does a lot of 
> tricks in their jmx impl. )
> - we still don't have the test suite for jmx - so licence issues are still
> there ( and we don't know if mx4j would pass it )
> - we'll be very dependent on JMX - with little control over implementation.
> - again, tomcat won't work without jmx.

BTW, I don't see performance being much worse than the current solution, 
which is already very slow, and is also completely based on introspection.

> 2. Wrapper->JMX for configuration. 
> We can use a small wrapper that will work without JMX. Something
> similar with modeler, but with no 'direct' dependency on JMX. We can
> register the components with this wrapper and use it to pass/query config
> info. If JMX is available, that will translate into JMX calls. 
> 
> One possible ( still standard ) API for the wrapper is JNDI. If we 
> register all the 'interesting' objects in the jndi we can easily 
> 'wrap' them for jmx. The APIs are very similar, the code is easy
> and most people are supposed to be familiar with the API. There
> are other choices as well.
> 
> We already depend on JNDI - so no extra deps here, and it'll probably 
> be easier to make it work with ldap or other backends.

Maybe.

> 3. Small config API ( with JMX hooks ). That's what I started in 
> util.config - just minimal objectName/attributes/attriubte change 
> notifications, no extra overhead. 
> That would probably be cleaner and smaller, but it's yet-another-api.

That's up to you. If you think it's useful to use a middle man between 
JMX and the Tomcat code, then I think it's good.

An advantage of that one may be that the (needed) refactoring of the 
config save may actually be clean, and that it abstracts the 
configuration storage (good).

> 4. Just keep the current API and implementation, with a jmx layer on top. 
> The listener provides access to the objects and allows it to transparently
> register them with JMX. We rewrite the config read to keep the information
> in memory and get all the changes made by user, then save. We could use
> DOM or something similar and preserve even the comments ( if XML backend
> is used ). 
> 
> The key difference is in what we use as a low-level API to 'assemble'
> the components. First 3 choices give more decoupling, the third is the
> easiest to implement ( almost nothing to change ).

The 3rd one looks the most interesting. It provides a good level of 
abstraction while being independent from JMX.

I'd be willing to help implement it.

Remy


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