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

[billbarker]

billbarker2003/10/10 23:10:00

  Modified:jk/java/org/apache/jk/common ModJkMX.java
  Log:
  Further attempts to get Gump to build.
  
  This patch is truely horrifying.  Please remove all small children from the room :(.
  
  At this point I'm +1 for excluding this file until it gets a proper maintainer.  It 
only adds some additional JMX-configuration options to mod_jk2.  Removing it doesn't 
effect any normal configuration.
  
  Revision  ChangesPath
  1.6   +6 -2  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java
  
  Index: ModJkMX.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ModJkMX.java  10 Oct 2003 04:08:31 -  1.5
  +++ ModJkMX.java  11 Oct 2003 06:10:00 -  1.6
  @@ -175,8 +175,12 @@
   Iterator mbeansIt=mbeans.values().iterator();
   while( mbeansIt.hasNext()) {
   MBeanProxy proxy=(MBeanProxy)mbeansIt.next();
  -ObjectName oname=proxy.getObjectName();
  -Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
  +Object ooname = proxy.getObjectName();
  +if( ooname != null ) {
  +String soname = ooname.toString();
  +ObjectName oname = new ObjectName(soname);
  +Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
  +}
   }
   } catch( Throwable t ) {
   log.error( "Destroy error", t );
  
  
  

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

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

[billbarker]

billbarker2003/10/10 21:34:24

  Modified:webapps/docs ssl-howto.xml
  Log:
  Document new configuration value.
  
  Revision  ChangesPath
  1.8   +7 -0  jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml
  
  Index: ssl-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ssl-howto.xml 5 Oct 2003 23:53:52 -   1.7
  +++ ssl-howto.xml 11 Oct 2003 04:34:24 -  1.8
  @@ -378,6 +378,13 @@
  truststorePass
  The password to access the TrustStore.
 
  +  
  +   truststoreType
  +Add this element if your are using a different format for the 
  +TrustStore then you are using for the KeyStore.  The valid values are
  +JKS and PKCS12.
  +
  +  
   
   
   After completing these configuration changes, you must restart Tomcat as
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE13SocketFactory.java JSSE14SocketFactory.java

[billbarker]

billbarker2003/10/10 21:24:30

  Modified:util/java/org/apache/tomcat/util/net/jsse
JSSE13SocketFactory.java JSSE14SocketFactory.java
  Log:
  Allow the TrustStore to have a different type from the KeyStore.
  
  Probably a small minority case, but it can be useful when moving from Apache to 
Tomcat-Standalone.
  
  Revision  ChangesPath
  1.6   +5 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java
  
  Index: JSSE13SocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JSSE13SocketFactory.java  2 Sep 2003 21:34:38 -   1.5
  +++ JSSE13SocketFactory.java  11 Oct 2003 04:24:30 -  1.6
  @@ -131,7 +131,11 @@
   
   // Set up TrustManager
   com.sun.net.ssl.TrustManager[] tm = null;
  -KeyStore trustStore = getTrustStore(keystoreType);
  +String truststoreType = (String)attributes.get("truststoreType");
  +if(truststoreType == null) {
  +truststoreType = keystoreType;
  +}
  +KeyStore trustStore = getTrustStore(truststoreType);
   if (trustStore != null) {
   com.sun.net.ssl.TrustManagerFactory tmf =
   com.sun.net.ssl.TrustManagerFactory.getInstance("SunX509");
  
  
  
  1.16  +5 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
  
  Index: JSSE14SocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- JSSE14SocketFactory.java  27 Sep 2003 02:44:07 -  1.15
  +++ JSSE14SocketFactory.java  11 Oct 2003 04:24:30 -  1.16
  @@ -186,7 +186,11 @@
   
   TrustManager[] tms = null;
   
  -KeyStore trustStore = getTrustStore(keystoreType);
  +String truststoreType = (String)attributes.get("truststoreType");
  +if(truststoreType == null) {
  +truststoreType = keystoreType;
  +}
  +KeyStore trustStore = getTrustStore(truststoreType);
   if (trustStore != null) {
   TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm);
   tmf.init(trustStore);
  
  
  

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

RE: Webapp classloader question.

[Lee, William]

Hmm... Seems like even the Sun's engineer also have different point of views
between them as well... Now, I'm totally confused about which way should be
the right way to go...

It there any Sun/Java representative on this mailing list that can answer
this question then?

Thanks again for all your help.
William.


-Original Message-
From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 10, 2003 2:38 PM
To: 'Tomcat Developers List'
Subject: RE: Webapp classloader question.


here's one reply that I got a while ago about the issue when it was changed
in 4.0.2(saying basically the same thing)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg74261.html

I know that the WEB-INF classloader changes the delegation model by looking
for classes within WEB-INF BEFORE delegating to its parent, but I don't know
why the endorsed spec was chosen to override the servlet spec.

Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 2:13 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> To be honest, I got exactly the same impression when I read
> this document
> half a year ago. However, when I tried to clarify all the 
> "grey" areas in
> this document with Sun, here is the response from their Java engineer:
> 
> ***
> The standard "delegation model" used by Java does say that a child 
> classloader should look first to its parent classloader when searching 
> for classes.  As you know, this model works against us in your
> situtation, since
> the application classloader for a web app is a child of the 
> system class
> loader (where the 1.4 parsers are loaded).  However, the servlet
> specification requires that a web app obtain its class 
> definition from the
> WAR file.  Therefore, most vendors have implemented a way for the
> application classloader to look in the WAR file first before 
> going to a
> parent, thereby overriding the standard delegation model.
> ***
> 
> So, it seems to me that the servlet spec. should supersede
> the "endorsed
> mechanism" in the web application environment.
> 
> William.
> 
> -Original Message-
> From: Cox, Charlie [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 1:17 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> ok, I just found this link from the archives. Sun defined
> that you have to
> use the 'endorsed' directory or take the Sun-supplied versions of the
> packages listed.
> http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html
> 
> tomcat's classloading is enforcing this requirement
> explicitly since it does
> not delegate to the parent classloader first.
> 
> so you can only replace the version in /endorsed
> Charlie
> 
> > -Original Message-
> > From: Lee, William [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2003 12:05 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > It seems to me that we are going for "bandaid" solution here. By 
> > moving around the files, it will work for one particular webapp, but 
> > at the expensive of the compatibility of other webapp under the same
> > tomcat. As
> > soon as we move the parser out of one webapp, we are 
> forcing all other
> > webapp using the same parser, which I believed is not the
> > right way to go.
> > 
> > Rather, why forcing the delegate model for these two particular 
> > packages (xerces & xalan)? Isn't it true that the endorse mechanism
> > only required
> > that the endorsed directory should be traverse before the system?
> > 
> > I still didn't see the reason how this "endorsed mechanism" has 
> > anything to do with the servlet spec., and that it would force 
> > servlet container to skip
> > the one in webapps?
> > 
> > Thanks again.
> > William.
> > 
> > 
> > -Original Message-
> > From: Cox, Charlie [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2003 8:46 AM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > you want to put the one from endorsed into server/lib, then put 
> > yours in WEB-INF. This way only one is visible to any tree of the
> > classloader. But
> > I'm not sure if you will still end up with the JDK version 
> > since the one in
> > WEB-INF is not "endorsed" to override it.
> > 
> > The other thing I would try is to put your version in 
> > /common/endorsed with the tomcat version in /server/lib.
> > 
> > btw, have you just tried replacing the version in /endorsed with 
> > your newer one?
> > 
> > Charlie
> > 
> > > -Original Message-
> > > From: Lee, William [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, October 09, 2003 4:54 PM
> > > To: 'Tomcat Developers List'
> > > Subject: RE: Webapp classloader question.
> > > 
> > > 
> > > This won't work since, all jar files in commons/lib,
> > > commons/endorsed, and commons/classes are all visible to the 
> > > tomcat's "commons" classlo

RE: Webapp classloader question.

[Cox, Charlie]

here's one reply that I got a while ago about the issue when it was changed
in 4.0.2(saying basically the same thing)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg74261.html

I know that the WEB-INF classloader changes the delegation model by looking
for classes within WEB-INF BEFORE delegating to its parent, but I don't know
why the endorsed spec was chosen to override the servlet spec.

Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 2:13 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> To be honest, I got exactly the same impression when I read 
> this document
> half a year ago. However, when I tried to clarify all the 
> "grey" areas in
> this document with Sun, here is the response from their Java engineer:
> 
> ***
> The standard "delegation model" used by Java does say that a child
> classloader should look first to its parent classloader when 
> searching for
> classes.  As you know, this model works against us in your 
> situtation, since
> the application classloader for a web app is a child of the 
> system class
> loader (where the 1.4 parsers are loaded).  However, the servlet
> specification requires that a web app obtain its class 
> definition from the
> WAR file.  Therefore, most vendors have implemented a way for the
> application classloader to look in the WAR file first before 
> going to a
> parent, thereby overriding the standard delegation model.
> ***
> 
> So, it seems to me that the servlet spec. should supersede 
> the "endorsed
> mechanism" in the web application environment.
> 
> William.
> 
> -Original Message-
> From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 10, 2003 1:17 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> ok, I just found this link from the archives. Sun defined 
> that you have to
> use the 'endorsed' directory or take the Sun-supplied versions of the
> packages listed.
> http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html
> 
> tomcat's classloading is enforcing this requirement 
> explicitly since it does
> not delegate to the parent classloader first.
> 
> so you can only replace the version in /endorsed
> Charlie
> 
> > -Original Message-
> > From: Lee, William [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2003 12:05 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > It seems to me that we are going for "bandaid" solution here.
> > By moving
> > around the files, it will work for one particular webapp, but at the
> > expensive of the compatibility of other webapp under the same 
> > tomcat. As
> > soon as we move the parser out of one webapp, we are 
> forcing all other
> > webapp using the same parser, which I believed is not the 
> > right way to go.
> > 
> > Rather, why forcing the delegate model for these two
> > particular packages
> > (xerces & xalan)? Isn't it true that the endorse mechanism 
> > only required
> > that the endorsed directory should be traverse before the system?
> > 
> > I still didn't see the reason how this "endorsed mechanism"
> > has anything to
> > do with the servlet spec., and that it would force servlet 
> > container to skip
> > the one in webapps?
> > 
> > Thanks again.
> > William.
> > 
> > 
> > -Original Message-
> > From: Cox, Charlie [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2003 8:46 AM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > you want to put the one from endorsed into server/lib, then
> > put yours in
> > WEB-INF. This way only one is visible to any tree of the 
> > classloader. But
> > I'm not sure if you will still end up with the JDK version 
> > since the one in
> > WEB-INF is not "endorsed" to override it.
> > 
> > The other thing I would try is to put your version in
> > /common/endorsed with
> > the tomcat version in /server/lib.
> > 
> > btw, have you just tried replacing the version in /endorsed
> > with your newer
> > one?
> > 
> > Charlie
> > 
> > > -Original Message-
> > > From: Lee, William [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, October 09, 2003 4:54 PM
> > > To: 'Tomcat Developers List'
> > > Subject: RE: Webapp classloader question.
> > > 
> > > 
> > > This won't work since, all jar files in commons/lib, 
> > > commons/endorsed, and commons/classes are all visible to the 
> > > tomcat's "commons" classloader. So,
> > > there is no difference whether we put the xerces jar files 
> > in "lib" or
> > > "endorsed", the one from webapps will be skipped.
> > > 
> > > I think the question boiled down to, if we have Xerces on both 
> > > "endorsed" and "webapps", which one should be used? For tomcat, I 
> > > would thought that
> > > the order for class searching will be "webapps", 
> "shared", "commons"
> > > (including "endorsed"), then "system".
> > > 
> > > I believed t

RE: Webapp classloader question.

[Lee, William]

To be honest, I got exactly the same impression when I read this document
half a year ago. However, when I tried to clarify all the "grey" areas in
this document with Sun, here is the response from their Java engineer:

***
The standard "delegation model" used by Java does say that a child
classloader should look first to its parent classloader when searching for
classes.  As you know, this model works against us in your situtation, since
the application classloader for a web app is a child of the system class
loader (where the 1.4 parsers are loaded).  However, the servlet
specification requires that a web app obtain its class definition from the
WAR file.  Therefore, most vendors have implemented a way for the
application classloader to look in the WAR file first before going to a
parent, thereby overriding the standard delegation model.
***

So, it seems to me that the servlet spec. should supersede the "endorsed
mechanism" in the web application environment.

William.

-Original Message-
From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 10, 2003 1:17 PM
To: 'Tomcat Developers List'
Subject: RE: Webapp classloader question.


ok, I just found this link from the archives. Sun defined that you have to
use the 'endorsed' directory or take the Sun-supplied versions of the
packages listed.
http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html

tomcat's classloading is enforcing this requirement explicitly since it does
not delegate to the parent classloader first.

so you can only replace the version in /endorsed
Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 12:05 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> It seems to me that we are going for "bandaid" solution here.
> By moving
> around the files, it will work for one particular webapp, but at the
> expensive of the compatibility of other webapp under the same 
> tomcat. As
> soon as we move the parser out of one webapp, we are forcing all other
> webapp using the same parser, which I believed is not the 
> right way to go.
> 
> Rather, why forcing the delegate model for these two
> particular packages
> (xerces & xalan)? Isn't it true that the endorse mechanism 
> only required
> that the endorsed directory should be traverse before the system?
> 
> I still didn't see the reason how this "endorsed mechanism"
> has anything to
> do with the servlet spec., and that it would force servlet 
> container to skip
> the one in webapps?
> 
> Thanks again.
> William.
> 
> 
> -Original Message-
> From: Cox, Charlie [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 8:46 AM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> you want to put the one from endorsed into server/lib, then
> put yours in
> WEB-INF. This way only one is visible to any tree of the 
> classloader. But
> I'm not sure if you will still end up with the JDK version 
> since the one in
> WEB-INF is not "endorsed" to override it.
> 
> The other thing I would try is to put your version in
> /common/endorsed with
> the tomcat version in /server/lib.
> 
> btw, have you just tried replacing the version in /endorsed
> with your newer
> one?
> 
> Charlie
> 
> > -Original Message-
> > From: Lee, William [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 09, 2003 4:54 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > This won't work since, all jar files in commons/lib, 
> > commons/endorsed, and commons/classes are all visible to the 
> > tomcat's "commons" classloader. So,
> > there is no difference whether we put the xerces jar files 
> in "lib" or
> > "endorsed", the one from webapps will be skipped.
> > 
> > I think the question boiled down to, if we have Xerces on both 
> > "endorsed" and "webapps", which one should be used? For tomcat, I 
> > would thought that
> > the order for class searching will be "webapps", "shared", "commons"
> > (including "endorsed"), then "system".
> > 
> > I believed tomcat put "endorsed" before "system" is to follows the 
> > "endorsed classloading spec.". But I also believed forcing delegate
> > model for xerces
> > and xalan maybe overkill?
> > 
> > Indeed, the tomcat's "class-loader-howto" document also indicated 
> > that the one from webapps should be used instead.
> > 
> > Frankly speaking, I'm no expert on these topics, so please feel free 
> > to correct me if I mis-understanding anything here.
> > 
> > Thanks.
> > William.
> > 
> > -Original Message-
> > From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 09, 2003 12:44 PM
> > To: Tomcat Developers List
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > 
> > Howdy,
> > Tomcat 4.1.x implements the endorsed classloader spec.  It's 
> > compliant with the Servlet Specification v2.3.  What you can do if 
> > you want your webapp t

RE: Webapp classloader question.

[Kevin Jones]

But the org.apache classes are not endorsed, only the org.xml.sax and
org.w3c.dom. These packages contain mostly interfaces and while the
implemenation of the JDK comes with the org.apache classes I do not
believe these are considered part of the J2SE platform API.

JAXP comes with a specific override mechanism such that if a JAXP
implementation is found on the classpath that one can be used ahead of
any other implementation. Otherwise developers would be stuck with the
JAXP parser in the JRE. This means that a parser in mywebapp/web-inf/lib
should be used ahead of any other provided you are using
SAXParserFactory/DocumentBuilderFactory to load the parser. At least
this is my reading of the JAXP specification and certainly the behaviour
I've seen running XML apps from the command line and making sure that I
have Xerces/Xalan on the classpath for the application.

BTW I'm butting in here assuming I know the whole thread, and this is
also a subject dear to my heart as I've had so many go arounds of this
on so many different Tomcat versions.

BTW2 the Servlet specification was written with exactly this problem in
mind, i.e. making sure the 'right' XML parser was loaded

Kevin Jones

On Fri, 2003-10-10 at 18:16, Cox, Charlie wrote:
> ok, I just found this link from the archives. Sun defined that you have to
> use the 'endorsed' directory or take the Sun-supplied versions of the
> packages listed.
> http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html
> 
> tomcat's classloading is enforcing this requirement explicitly since it does
> not delegate to the parent classloader first.
> 
> so you can only replace the version in /endorsed
> Charlie
> 
> > -Original Message-
> > From: Lee, William [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2003 12:05 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > It seems to me that we are going for "bandaid" solution here. 
> > By moving
> > around the files, it will work for one particular webapp, but at the
> > expensive of the compatibility of other webapp under the same 
> > tomcat. As
> > soon as we move the parser out of one webapp, we are forcing all other
> > webapp using the same parser, which I believed is not the 
> > right way to go.
> > 
> > Rather, why forcing the delegate model for these two 
> > particular packages
> > (xerces & xalan)? Isn't it true that the endorse mechanism 
> > only required
> > that the endorsed directory should be traverse before the system?
> > 
> > I still didn't see the reason how this "endorsed mechanism" 
> > has anything to
> > do with the servlet spec., and that it would force servlet 
> > container to skip
> > the one in webapps?
> > 
> > Thanks again.
> > William.
> > 
> > 
> > -Original Message-
> > From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, October 10, 2003 8:46 AM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > you want to put the one from endorsed into server/lib, then 
> > put yours in
> > WEB-INF. This way only one is visible to any tree of the 
> > classloader. But
> > I'm not sure if you will still end up with the JDK version 
> > since the one in
> > WEB-INF is not "endorsed" to override it.
> > 
> > The other thing I would try is to put your version in 
> > /common/endorsed with
> > the tomcat version in /server/lib.
> > 
> > btw, have you just tried replacing the version in /endorsed 
> > with your newer
> > one?
> > 
> > Charlie
> > 
> > > -Original Message-
> > > From: Lee, William [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, October 09, 2003 4:54 PM
> > > To: 'Tomcat Developers List'
> > > Subject: RE: Webapp classloader question.
> > > 
> > > 
> > > This won't work since, all jar files in commons/lib,
> > > commons/endorsed, and
> > > commons/classes are all visible to the tomcat's "commons" 
> > > classloader. So,
> > > there is no difference whether we put the xerces jar files 
> > in "lib" or
> > > "endorsed", the one from webapps will be skipped.
> > > 
> > > I think the question boiled down to, if we have Xerces on
> > > both "endorsed"
> > > and "webapps", which one should be used? For tomcat, I would 
> > > thought that
> > > the order for class searching will be "webapps", "shared", "commons"
> > > (including "endorsed"), then "system".
> > > 
> > > I believed tomcat put "endorsed" before "system" is to
> > > follows the "endorsed
> > > classloading spec.". But I also believed forcing delegate 
> > > model for xerces
> > > and xalan maybe overkill?
> > > 
> > > Indeed, the tomcat's "class-loader-howto" document also
> > > indicated that the
> > > one from webapps should be used instead.
> > > 
> > > Frankly speaking, I'm no expert on these topics, so please
> > > feel free to
> > > correct me if I mis-understanding anything here.
> > > 
> > > Thanks.
> > > William.
> > > 
> > > -Original Message-
> > > From: Shapira, Yoav [mailto:[EMAIL PROTECTE

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

[luehe]

luehe   2003/10/10 10:40:39

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Quote value of 'classid' attribute
  
  Revision  ChangesPath
  1.213 +11 -18
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.212
  retrieving revision 1.213
  diff -u -r1.212 -r1.213
  --- Generator.java22 Sep 2003 21:01:21 -  1.212
  +++ Generator.java10 Oct 2003 17:40:38 -  1.213
  @@ -1449,9 +1449,8 @@
   // IE style plugin
   // 
   // First compose the runtime output string 
  -String s0 =
  -" for java_codebase
   if (codebase != null) {
  -s0 =
  -"';
   out.printil("out.write(" + quote(s0) + ");");
  @@ -1493,8 +1490,7 @@
   
   //  for java_archive
   if (archive != null) {
  -s0 =
  -"';
   out.printil("out.write(" + quote(s0) + ");");
  @@ -1502,8 +1498,7 @@
   }
   
   //  for type
  -s0 =
  -"") + ");");
   out.printil("out.write(\"\\n\");");
  -s0 =
  -"

RE: Webapp classloader question.

[Cox, Charlie]

ok, I just found this link from the archives. Sun defined that you have to
use the 'endorsed' directory or take the Sun-supplied versions of the
packages listed.
http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html

tomcat's classloading is enforcing this requirement explicitly since it does
not delegate to the parent classloader first.

so you can only replace the version in /endorsed
Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 12:05 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> It seems to me that we are going for "bandaid" solution here. 
> By moving
> around the files, it will work for one particular webapp, but at the
> expensive of the compatibility of other webapp under the same 
> tomcat. As
> soon as we move the parser out of one webapp, we are forcing all other
> webapp using the same parser, which I believed is not the 
> right way to go.
> 
> Rather, why forcing the delegate model for these two 
> particular packages
> (xerces & xalan)? Isn't it true that the endorse mechanism 
> only required
> that the endorsed directory should be traverse before the system?
> 
> I still didn't see the reason how this "endorsed mechanism" 
> has anything to
> do with the servlet spec., and that it would force servlet 
> container to skip
> the one in webapps?
> 
> Thanks again.
> William.
> 
> 
> -Original Message-
> From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 10, 2003 8:46 AM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> you want to put the one from endorsed into server/lib, then 
> put yours in
> WEB-INF. This way only one is visible to any tree of the 
> classloader. But
> I'm not sure if you will still end up with the JDK version 
> since the one in
> WEB-INF is not "endorsed" to override it.
> 
> The other thing I would try is to put your version in 
> /common/endorsed with
> the tomcat version in /server/lib.
> 
> btw, have you just tried replacing the version in /endorsed 
> with your newer
> one?
> 
> Charlie
> 
> > -Original Message-
> > From: Lee, William [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 09, 2003 4:54 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > This won't work since, all jar files in commons/lib,
> > commons/endorsed, and
> > commons/classes are all visible to the tomcat's "commons" 
> > classloader. So,
> > there is no difference whether we put the xerces jar files 
> in "lib" or
> > "endorsed", the one from webapps will be skipped.
> > 
> > I think the question boiled down to, if we have Xerces on
> > both "endorsed"
> > and "webapps", which one should be used? For tomcat, I would 
> > thought that
> > the order for class searching will be "webapps", "shared", "commons"
> > (including "endorsed"), then "system".
> > 
> > I believed tomcat put "endorsed" before "system" is to
> > follows the "endorsed
> > classloading spec.". But I also believed forcing delegate 
> > model for xerces
> > and xalan maybe overkill?
> > 
> > Indeed, the tomcat's "class-loader-howto" document also
> > indicated that the
> > one from webapps should be used instead.
> > 
> > Frankly speaking, I'm no expert on these topics, so please
> > feel free to
> > correct me if I mis-understanding anything here.
> > 
> > Thanks.
> > William.
> > 
> > -Original Message-
> > From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 09, 2003 12:44 PM
> > To: Tomcat Developers List
> > Subject: RE: Webapp classloader question.
> > 
> > 
> > 
> > Howdy,
> > Tomcat 4.1.x implements the endorsed classloader spec.  It's
> > compliant with
> > the Servlet Specification v2.3.  What you can do if you want 
> > your webapp to
> > use the latest xerces/JAXP, is:
> > - Move $CATALINA_HOME/common/endorsed/* to $CATALINA_HOME/common/lib
> > - Put your later xerces etc. in WEB-INF/lib as you've been doing.
> > 
> > Yoav Shapira
> > Millennium ChemInformatics
> > 
> > 
> > >-Original Message-
> > >From: Lee, William [mailto:[EMAIL PROTECTED]
> > >Sent: Thursday, October 09, 2003 12:38 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Webapp classloader question.
> > >
> > >
> > >Hi all,
> > >
> > >I'm not sure if this message reaches you guys yet, so here
> > it go again.
> > >Sorry for any inconvenience if you receiving this message twice.
> > >
> > >Thanks.
> > >William.
> > >
> > >-Original Message-
> > >From: Lee, William [mailto:[EMAIL PROTECTED]
> > >Sent: Tuesday, October 07, 2003 3:55 PM
> > >To: '[EMAIL PROTECTED]'
> > >Subject: Webapp classloader question.
> > >
> > >
> > >Hi all,
> > >
> > >When moving from tomcat 4.0.x to 4.1.x, we discovered that the
> > >WebappClassLoader.java had been changed such that all classes from 
> > >"org.apache.xerces" and "org.apache.xalan" are forced to be loaded
> > using
> > >the
> > >delegate model f

RE: Webapp classloader question.

[Lee, William]

It seems to me that we are going for "bandaid" solution here. By moving
around the files, it will work for one particular webapp, but at the
expensive of the compatibility of other webapp under the same tomcat. As
soon as we move the parser out of one webapp, we are forcing all other
webapp using the same parser, which I believed is not the right way to go.

Rather, why forcing the delegate model for these two particular packages
(xerces & xalan)? Isn't it true that the endorse mechanism only required
that the endorsed directory should be traverse before the system?

I still didn't see the reason how this "endorsed mechanism" has anything to
do with the servlet spec., and that it would force servlet container to skip
the one in webapps?

Thanks again.
William.


-Original Message-
From: Cox, Charlie [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 10, 2003 8:46 AM
To: 'Tomcat Developers List'
Subject: RE: Webapp classloader question.


you want to put the one from endorsed into server/lib, then put yours in
WEB-INF. This way only one is visible to any tree of the classloader. But
I'm not sure if you will still end up with the JDK version since the one in
WEB-INF is not "endorsed" to override it.

The other thing I would try is to put your version in /common/endorsed with
the tomcat version in /server/lib.

btw, have you just tried replacing the version in /endorsed with your newer
one?

Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2003 4:54 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> This won't work since, all jar files in commons/lib,
> commons/endorsed, and
> commons/classes are all visible to the tomcat's "commons" 
> classloader. So,
> there is no difference whether we put the xerces jar files in "lib" or
> "endorsed", the one from webapps will be skipped.
> 
> I think the question boiled down to, if we have Xerces on
> both "endorsed"
> and "webapps", which one should be used? For tomcat, I would 
> thought that
> the order for class searching will be "webapps", "shared", "commons"
> (including "endorsed"), then "system".
> 
> I believed tomcat put "endorsed" before "system" is to
> follows the "endorsed
> classloading spec.". But I also believed forcing delegate 
> model for xerces
> and xalan maybe overkill?
> 
> Indeed, the tomcat's "class-loader-howto" document also
> indicated that the
> one from webapps should be used instead.
> 
> Frankly speaking, I'm no expert on these topics, so please
> feel free to
> correct me if I mis-understanding anything here.
> 
> Thanks.
> William.
> 
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2003 12:44 PM
> To: Tomcat Developers List
> Subject: RE: Webapp classloader question.
> 
> 
> 
> Howdy,
> Tomcat 4.1.x implements the endorsed classloader spec.  It's
> compliant with
> the Servlet Specification v2.3.  What you can do if you want 
> your webapp to
> use the latest xerces/JAXP, is:
> - Move $CATALINA_HOME/common/endorsed/* to $CATALINA_HOME/common/lib
> - Put your later xerces etc. in WEB-INF/lib as you've been doing.
> 
> Yoav Shapira
> Millennium ChemInformatics
> 
> 
> >-Original Message-
> >From: Lee, William [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, October 09, 2003 12:38 PM
> >To: [EMAIL PROTECTED]
> >Subject: Webapp classloader question.
> >
> >
> >Hi all,
> >
> >I'm not sure if this message reaches you guys yet, so here
> it go again.
> >Sorry for any inconvenience if you receiving this message twice.
> >
> >Thanks.
> >William.
> >
> >-Original Message-
> >From: Lee, William [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, October 07, 2003 3:55 PM
> >To: '[EMAIL PROTECTED]'
> >Subject: Webapp classloader question.
> >
> >
> >Hi all,
> >
> >When moving from tomcat 4.0.x to 4.1.x, we discovered that the
> >WebappClassLoader.java had been changed such that all classes from 
> >"org.apache.xerces" and "org.apache.xalan" are forced to be loaded
> using
> >the
> >delegate model first, before looking into the webapp directory. This
> seems
> >to related to the JDK 1.4 support of the xml and xslt parser.
> >
> >However, after a long conversation with the Sun's Java engineer, he
> point
> >out that, even JDK 1.4 shipped with the default xml and xslt parser,
> >application server and servlet container should continue to 
> use the one
> >provided from the webapp directory as described in the servlet spec.
> 2.3.
> >
> >Could someone please hint some lights on why tomcat 4.1.x decided to
> >enforce the delegate model for these two packages?
> >
> >(The reason I'm asking is that, we try to use the latest
> Xerces in our
> >webapps, and since it always look and found the one from
> common/endorsed
> >directory, our latest version will always be skipped.)
> >
> >Thanks in advance for your help.
> >William.
> >
> >Join us at Cognos' biggest event of the year Enterprise 200

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

[remm]

remm2003/10/10 08:42:20

  Modified:catalina/src/bin catalina.sh
  Log:
  - Explicitely add commons-logging-api on the classpath on Unix.
  
  Revision  ChangesPath
  1.10  +2 -2  jakarta-tomcat-catalina/catalina/src/bin/catalina.sh
  
  Index: catalina.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/catalina.sh,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- catalina.sh   2 Oct 2003 17:07:40 -   1.9
  +++ catalina.sh   10 Oct 2003 15:42:20 -  1.10
  @@ -101,7 +101,7 @@
   if [ -n "$JSSE_HOME" ]; then
 
CLASSPATH="$CLASSPATH":"$JSSE_HOME"/lib/jcert.jar:"$JSSE_HOME"/lib/jnet.jar:"$JSSE_HOME"/lib/jsse.jar
   fi
  -CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar
  
+CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar:"$CATALINA_HOME"/bin/commons-logging-api.jar
   
   if [ -z "$CATALINA_BASE" ] ; then
 CATALINA_BASE="$CATALINA_HOME"
  
  
  

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

RE: Webapp classloader question.

[Cox, Charlie]

you want to put the one from endorsed into server/lib, then put yours in
WEB-INF. This way only one is visible to any tree of the classloader. But
I'm not sure if you will still end up with the JDK version since the one in
WEB-INF is not "endorsed" to override it.

The other thing I would try is to put your version in /common/endorsed with
the tomcat version in /server/lib.

btw, have you just tried replacing the version in /endorsed with your newer
one?

Charlie

> -Original Message-
> From: Lee, William [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2003 4:54 PM
> To: 'Tomcat Developers List'
> Subject: RE: Webapp classloader question.
> 
> 
> This won't work since, all jar files in commons/lib, 
> commons/endorsed, and
> commons/classes are all visible to the tomcat's "commons" 
> classloader. So,
> there is no difference whether we put the xerces jar files in "lib" or
> "endorsed", the one from webapps will be skipped.
> 
> I think the question boiled down to, if we have Xerces on 
> both "endorsed"
> and "webapps", which one should be used? For tomcat, I would 
> thought that
> the order for class searching will be "webapps", "shared", "commons"
> (including "endorsed"), then "system".
> 
> I believed tomcat put "endorsed" before "system" is to 
> follows the "endorsed
> classloading spec.". But I also believed forcing delegate 
> model for xerces
> and xalan maybe overkill?
> 
> Indeed, the tomcat's "class-loader-howto" document also 
> indicated that the
> one from webapps should be used instead.
> 
> Frankly speaking, I'm no expert on these topics, so please 
> feel free to
> correct me if I mis-understanding anything here.
> 
> Thanks.
> William.
> 
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, October 09, 2003 12:44 PM
> To: Tomcat Developers List
> Subject: RE: Webapp classloader question.
> 
> 
> 
> Howdy,
> Tomcat 4.1.x implements the endorsed classloader spec.  It's 
> compliant with
> the Servlet Specification v2.3.  What you can do if you want 
> your webapp to
> use the latest xerces/JAXP, is:
> - Move $CATALINA_HOME/common/endorsed/* to $CATALINA_HOME/common/lib
> - Put your later xerces etc. in WEB-INF/lib as you've been doing.
> 
> Yoav Shapira
> Millennium ChemInformatics
> 
> 
> >-Original Message-
> >From: Lee, William [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, October 09, 2003 12:38 PM
> >To: [EMAIL PROTECTED]
> >Subject: Webapp classloader question.
> >
> >
> >Hi all,
> >
> >I'm not sure if this message reaches you guys yet, so here 
> it go again. 
> >Sorry for any inconvenience if you receiving this message twice.
> >
> >Thanks.
> >William.
> >
> >-Original Message-
> >From: Lee, William [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, October 07, 2003 3:55 PM
> >To: '[EMAIL PROTECTED]'
> >Subject: Webapp classloader question.
> >
> >
> >Hi all,
> >
> >When moving from tomcat 4.0.x to 4.1.x, we discovered that the 
> >WebappClassLoader.java had been changed such that all classes from 
> >"org.apache.xerces" and "org.apache.xalan" are forced to be loaded
> using
> >the
> >delegate model first, before looking into the webapp directory. This
> seems
> >to related to the JDK 1.4 support of the xml and xslt parser.
> >
> >However, after a long conversation with the Sun's Java engineer, he
> point
> >out that, even JDK 1.4 shipped with the default xml and xslt parser, 
> >application server and servlet container should continue to 
> use the one 
> >provided from the webapp directory as described in the servlet spec.
> 2.3.
> >
> >Could someone please hint some lights on why tomcat 4.1.x decided to 
> >enforce the delegate model for these two packages?
> >
> >(The reason I'm asking is that, we try to use the latest 
> Xerces in our 
> >webapps, and since it always look and found the one from
> common/endorsed
> >directory, our latest version will always be skipped.)
> >
> >Thanks in advance for your help.
> >William.
> >
> >Join us at Cognos' biggest event of the year Enterprise 2003, The
> Cognos
> >Business Forum.  Taking place in over 25 cities around the 
> world, it's
> an
> >opportunity for Business and IT leaders to learn about 
> strategies for 
> >driving performance. Visit 
http://www.cognos.com/enterprise03 for more 
>details.
>
>This message may contain privileged and/or confidential information.
If
>you
>have received this e-mail in error or are not the intended recipient,
you
>may not use, copy, disseminate or distribute it; do not open any 
>attachments, delete it immediately from your system and notify the
sender
>promptly by e-mail that you have done so.  Thank you.



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are no

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

[remm]

remm2003/10/10 05:16:37

  Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
  Log:
  - Small tweaks to allow to execute the bootstrap JAR. This won't set any
endorsed properties (maybe there's an entry for that in the manifest, but
I don't know it), but could be useful.
  
  Revision  ChangesPath
  1.13  +22 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Bootstrap.java23 Sep 2003 13:43:18 -  1.12
  +++ Bootstrap.java10 Oct 2003 12:16:37 -  1.13
  @@ -380,7 +380,10 @@
   }
   
   try {
  -String command = args[0];
  +String command = "start";
  +if (args.length > 0) {
  +command = args[0];
  +}
   if (command.equals("startd")) {
   args[0] = "start";
   daemon.load(args);
  @@ -436,8 +439,23 @@
   
   if (System.getProperty("catalina.home") != null)
   return;
  -System.setProperty("catalina.home",
  -   System.getProperty("user.dir"));
  +File bootstrapJar = 
  +new File(System.getProperty("user.dir"), "bootstrap.jar");
  +if (bootstrapJar.exists()) {
  +try {
  +System.setProperty
  +("catalina.home", 
  + (new File(System.getProperty("user.dir"), ".."))
  + .getCanonicalPath());
  +} catch (Exception e) {
  +// Ignore
  +System.setProperty("catalina.home",
  +   System.getProperty("user.dir"));
  +}
  +} else {
  +System.setProperty("catalina.home",
  +   System.getProperty("user.dir"));
  +}
   
   }
   
  
  
  

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

RE: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[Ignacio J. Ortega]

Mladen Escribio:

> 
> So, find the space that can be reached from ant when building Tomcat5,
> and I'll put the binaries there,
> since we don't need them for anything but the nsis TC5 
> install package. 
> 

Ok, it seems reasonable, why dont release it as nigthlie, and put it
where the nigthlies are just now ( i'm very out of sight on this, where
are the nigthlies for any project just now, gumped? ), when a release
comes ( is a release of procrun planned?) where the releases lie as
ever.. not in cvs.. 

Saludos,
Ignacio J. Ortega


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

Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[Henri Gomez]

Mladen Turk a écrit :


-Original Message-
From: jean-frederic clere
Remy Maucherat wrote:

Ignacio J. Ortega wrote:

Sorry to disagree, but it's impossible to build the said binaries
without expensive compilers. (please do not suggest Cygwin)
Why? Is the Makefile broken?



Doesn't matter. We need the tomcat.exe and tomcatw.exe only.
While the tomcat.exe could be compiled using cygwin or mingw, there is a
problem with tomcatw.exe. The GNU's resource compilers doesn't handle
the
BITMAP resources so we are missing those whenever building with those
tools.
Also I'm not sure about the License and Cygwin binaries (that's too
fuzzy, so I don't even bother to compile something with cygwin).
AFAICT we don't build WIN32 distributable binaries with those tools for
any j-t-c project.
Further more, apache2.x installation is build with InstallShield
(another expensive tool), and
nobody complains about that.
ASF (or just Apache Team) have a special aggrement with InstallShield so
they could use it.
May be we should ask the same to Microsoft for it's Visual C++ ;--)



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

Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[jean-frederic clere]

Mladen Turk wrote:

-Original Message-
From: jean-frederic clere
Remy Maucherat wrote:

Ignacio J. Ortega wrote:

Sorry to disagree, but it's impossible to build the said binaries
without expensive compilers. (please do not suggest Cygwin)
Why? Is the Makefile broken?



Doesn't matter. We need the tomcat.exe and tomcatw.exe only.
While the tomcat.exe could be compiled using cygwin or mingw, there is a
problem with tomcatw.exe. The GNU's resource compilers doesn't handle
the
BITMAP resources so we are missing those whenever building with those
tools.
Ok, I have noted the resources were missing but I have not tried to arrange it.

Also I'm not sure about the License and Cygwin binaries (that's too
fuzzy, so I don't even bother to compile something with cygwin).
I will try to ask them.

AFAICT we don't build WIN32 distributable binaries with those tools for
any j-t-c project.
Further more, apache2.x installation is build with InstallShield
(another expensive tool), and
nobody complains about that.
:-((

So, find the space that can be reached from ant when building Tomcat5,
and I'll put the binaries there,
since we don't need them for anything but the nsis TC5 install package.
I do not want to remove the binaries now, I am just reaching a "Open Source" way 
to produce them.




So -1 to remove them, I need them where they are.



As I said, you need them where they can be found duiring build process.

MT.

-
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: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[jean-frederic clere]

Bill Barker wrote:
- Original Message - 
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 12:52 AM
Subject: Re: Committing binaries in CVS [Was] RE: cvs commit:
jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe



Remy Maucherat wrote:

Ignacio J. Ortega wrote:


Hola a todos:
(Many time from my last post, things are settling here, so hope i will
contribute some code in future :) shields up, nacho will be messing
things shortly, now i'm only moderating our lists, and as some person
said time ago "moderation is to coding what washing dishes is to
cooking" :))
I know this was discussed before, but i dont really understand why it's
needed to have a binary (moreover a win32 binary ) in CVS, and if there
isn't a very good reason to do so, i'm against, and if there is a very
good reason, i hope i should be applicable to any other binary we
produce.. thing that i sincerely doubt ..


Sorry to disagree, but it's impossible to build the said binaries
without expensive compilers. (please do not suggest Cygwin)
Why? Is the Makefile broken?



AFAIK, no.  It's just that Remy can't publish a version that requires
Cygwin.
It does not require cygwin.

 And, as Remy has pointed out, to build a version of procrun that
runs under a plain-vanilla install of Windows requires that you have a
commercial (read MSVC) compiler.  The cost of requiring this is just too
high to demand of an O/S project.  Now, if someone wants to suggest an O/S
C-compiler for Windows that doesn't require Cygwin, I'm all ears :).

So -1 to remove them, I need them where they are.

Remy



-
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]







-
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: [5.0.13] [4.1.28] VOTES

[jean-frederic clere]

Remy Maucherat wrote:
jean-frederic clere wrote:

Remy Maucherat wrote:

For 4.1.28:

[ ] Alpha
[x] Beta
[ ] Stable



My BS2000 is still not working OK.


Is it some kind of server powered by alien technology ? Or does it mean 
Bulls*** 2000 ? Cool name for a server if it does :-D
Best Server 2000 :-)

Anyway, I don't think anyone here can fix this without some help. First, 
is it a regression over older TC 4.1.x releases ?
No that is no regression, just that I need a little more time to finish my 
(EBCDIC) porting. But the problems I have found (and started to fix) may also 
exist on other platforms and there are quite a lot of change in this new release.

Remy



-
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: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[Mladen Turk]

> -Original Message-
> From: jean-frederic clere
> 
> Remy Maucherat wrote:
> > Ignacio J. Ortega wrote:
> > 
> > 
> > Sorry to disagree, but it's impossible to build the said binaries
> > without expensive compilers. (please do not suggest Cygwin)
> 
> Why? Is the Makefile broken?
>

Doesn't matter. We need the tomcat.exe and tomcatw.exe only.
While the tomcat.exe could be compiled using cygwin or mingw, there is a
problem with tomcatw.exe. The GNU's resource compilers doesn't handle
the
BITMAP resources so we are missing those whenever building with those
tools.
Also I'm not sure about the License and Cygwin binaries (that's too
fuzzy, so I don't even bother to compile something with cygwin).

AFAICT we don't build WIN32 distributable binaries with those tools for
any j-t-c project.
Further more, apache2.x installation is build with InstallShield
(another expensive tool), and
nobody complains about that.

So, find the space that can be reached from ant when building Tomcat5,
and I'll put the binaries there,
since we don't need them for anything but the nsis TC5 install package. 


> > 
> > So -1 to remove them, I need them where they are.
> > 

As I said, you need them where they can be found duiring build process.

MT.


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

Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[Bill Barker]

- Original Message - 
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 12:52 AM
Subject: Re: Committing binaries in CVS [Was] RE: cvs commit:
jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe


> Remy Maucherat wrote:
> > Ignacio J. Ortega wrote:
> >
> >> Hola a todos:
> >> (Many time from my last post, things are settling here, so hope i will
> >> contribute some code in future :) shields up, nacho will be messing
> >> things shortly, now i'm only moderating our lists, and as some person
> >> said time ago "moderation is to coding what washing dishes is to
> >> cooking" :))
> >>
> >> I know this was discussed before, but i dont really understand why it's
> >> needed to have a binary (moreover a win32 binary ) in CVS, and if there
> >> isn't a very good reason to do so, i'm against, and if there is a very
> >> good reason, i hope i should be applicable to any other binary we
> >> produce.. thing that i sincerely doubt ..
> >
> >
> > Sorry to disagree, but it's impossible to build the said binaries
> > without expensive compilers. (please do not suggest Cygwin)
>
> Why? Is the Makefile broken?
>

AFAIK, no.  It's just that Remy can't publish a version that requires
Cygwin.  And, as Remy has pointed out, to build a version of procrun that
runs under a plain-vanilla install of Windows requires that you have a
commercial (read MSVC) compiler.  The cost of requiring this is just too
high to demand of an O/S project.  Now, if someone wants to suggest an O/S
C-compiler for Windows that doesn't require Cygwin, I'm all ears :).

> >
> > So -1 to remove them, I need them where they are.
> >
> > Remy
> >
> >
> >
> > -
> > 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]
>
>


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: Re: TOMCAT-fix for os/390??

[Bill Barker]

Try http://www.apache.org/dist/jakarta/tomcat-4/v4.1.28-alpha/.  The 'alpha'
is just because it is still in it's evaluation stage.  It's likely to
graduate to at least beta (if not 'stable').  However, your ability to test
it on an os/390 system makes you particularly valuable to the developers, so
I hope that you will try it out :).

- Original Message - 
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 12:35 AM
Subject: Re: Re: TOMCAT-fix for os/390??


> Well well ...  being a simpleton (=user) I don't quite manage to manage
cvs ...
> I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find
such a distribution.
> So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA -
does it go well with JDK 1.3?
>
> thank you very much for your help
> Anna
> >
> > Von: Dirk Verbeeck <[EMAIL PROTECTED]>
> > Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00
> > An: Tomcat Developers List <[EMAIL PROTECTED]>
> > Betreff: Re: TOMCAT-fix for os/390??
> >
> > Hi Anna
> >
> > I don't use tomcat on os390 but by reading you problem I suspect your
> > problem is solved in cvs, you need at least revision 1.16.2.1
> >

> > or 1.18
> >

> > of the following file:
> >
http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
> >
> > Releases including this fix are TOMCAT_5_0_13
> >

,
> > TOMCAT_5_0_12
> >

,
> > TOMCAT_4_1_28
> >

> >
> > Cheers
> > Dirk
> >
> > Anna Fuhrmann wrote:
> >
> > >Hi all,
> > >like  a good girl I have been using the user-mailing-list up to now to
search for
> > >user experience installing tomcat on os390.
> > >
> > >Most (if not all) contributions are in the form "has anyone
successfully installed
> > >tomcat on os390?" From some other I got partly valuable ideas.
> > >
> > >I have been TRYING to get tomcat run on os390 in the last couple of
days.
> > >Done everything I could - everything seems to be allright up to this
pont: tomcat IS running at last
> > >without any serious signs of disbehaviour - no error messages at all,
xml's behaving well. But if we connect to
> > >localhost:tomcatport/index.jsp  (or wahtever else for that matter), the
browser does not show
> > >anything. Doing the same with a perl script shows that the server is
ansering and is supplying the
> > >requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID
> > >(i.e.: ebcdic) LINE SEPARATOR. So thats the reason why.
> > >
> > >Today I tried to identify the .java-file giving us the header (looking
for \r\n) . I thought I found it,
> > >by my hex.editor did not show me any 0x0d15 (which ought to be the
suspect, i.e. Newline
> > >in ebcdic).
> > >
> > >What I would like to know: Is there any kind of patch for os/390? Do
you have any suggestions?
> > >Is anybody working on it? What should I do? I want to have this beast
running.
> > >
> > >PLEASE.
> > >
> > >We have os390 2.10
> > >IBM-JDK 1.3
> > >tomcat 4.1.27
> > >
> > >Anna Fuhrmann
> > >
> > >
> >
> >
> >
> >
> > -
> > 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]
>
>


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

Re: [5.0.13] [4.1.28] VOTES

[Remy Maucherat]

jean-frederic clere wrote:
Remy Maucherat wrote:

For 4.1.28:

[ ] Alpha
[x] Beta
[ ] Stable

My BS2000 is still not working OK.
Is it some kind of server powered by alien technology ? Or does it mean 
Bulls*** 2000 ? Cool name for a server if it does :-D

Anyway, I don't think anyone here can fix this without some help. First, 
is it a regression over older TC 4.1.x releases ?

Remy



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

Re: [5.0.13] [4.1.28] VOTES

[jean-frederic clere]

Remy Maucherat wrote:
For 4.1.28:

[ ] Alpha
[x] Beta
[ ] Stable

My BS2000 is still not working OK.

For 5.0.13:

[ ] Alpha
[ ] Beta

Remy



-
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: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

[jean-frederic clere]

Remy Maucherat wrote:
Ignacio J. Ortega wrote:

Hola a todos:
(Many time from my last post, things are settling here, so hope i will
contribute some code in future :) shields up, nacho will be messing
things shortly, now i'm only moderating our lists, and as some person
said time ago "moderation is to coding what washing dishes is to
cooking" :))
I know this was discussed before, but i dont really understand why it's
needed to have a binary (moreover a win32 binary ) in CVS, and if there
isn't a very good reason to do so, i'm against, and if there is a very
good reason, i hope i should be applicable to any other binary we
produce.. thing that i sincerely doubt ..


Sorry to disagree, but it's impossible to build the said binaries 
without expensive compilers. (please do not suggest Cygwin)
Why? Is the Makefile broken?

So -1 to remove them, I need them where they are.

Remy



-
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: Re: TOMCAT-fix for os/390??

[anna.fuhrmann]

Well well ...  being a simpleton (=user) I don't quite manage to manage cvs ...
I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find such a 
distribution.
So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA - does it go 
well with JDK 1.3? 

thank you very much for your help 
Anna
> 
> Von: Dirk Verbeeck <[EMAIL PROTECTED]>
> Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00
> An: Tomcat Developers List <[EMAIL PROTECTED]>
> Betreff: Re: TOMCAT-fix for os/390??
> 
> Hi Anna
> 
> I don't use tomcat on os390 but by reading you problem I suspect your 
> problem is solved in cvs, you need at least revision 1.16.2.1 
> 
>  
> or 1.18 
> 
>  
> of the following file:
> http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
> 
> Releases including this fix are TOMCAT_5_0_13 
> ,
>  
> TOMCAT_5_0_12 
> ,
>  
> TOMCAT_4_1_28 
> 
> 
> Cheers
> Dirk
> 
> Anna Fuhrmann wrote:
> 
> >Hi all,
> >like  a good girl I have been using the user-mailing-list up to now to search for
> >user experience installing tomcat on os390.
> >
> >Most (if not all) contributions are in the form "has anyone successfully installed
> >tomcat on os390?" From some other I got partly valuable ideas. 
> >
> >I have been TRYING to get tomcat run on os390 in the last couple of days.
> >Done everything I could - everything seems to be allright up to this pont: tomcat 
> >IS running at last
> >without any serious signs of disbehaviour - no error messages at all, xml's 
> >behaving well. But if we connect to
> >localhost:tomcatport/index.jsp  (or wahtever else for that matter), the browser 
> >does not show
> >anything. Doing the same with a perl script shows that the server is ansering and 
> >is supplying the 
> >requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID
> >(i.e.: ebcdic) LINE SEPARATOR. So thats the reason why. 
> >
> >Today I tried to identify the .java-file giving us the header (looking for \r\n) . 
> >I thought I found it, 
> >by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. 
> >Newline
> >in ebcdic). 
> >
> >What I would like to know: Is there any kind of patch for os/390? Do you have any 
> >suggestions?
> >Is anybody working on it? What should I do? I want to have this beast running.
> >
> >PLEASE.
> >
> >We have os390 2.10
> >IBM-JDK 1.3
> >tomcat 4.1.27
> >
> >Anna Fuhrmann   
> >  
> >
> 
> 
> 
> 
> -
> 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-connectors/jk/native configure.in

[hgomez]

hgomez  2003/10/10 00:35:22

  Modified:jk/native configure.in
  Log:
  APR includes could be in a differents location that Apache 2.0 includes.
  For instance Redhat use 2 locations in it's RawHide version of 2.0.47
  
  Revision  ChangesPath
  1.26  +3 -2  jakarta-tomcat-connectors/jk/native/configure.in
  
  Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- configure.in  24 Jul 2003 08:15:22 -  1.25
  +++ configure.in  10 Oct 2003 07:35:22 -  1.26
  @@ -100,7 +100,8 @@
APXS_CPPFLAGS=""
   else
   WEBSERVER="apache-2.0"
  - APXSCFLAGS="`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS` 
-DHAVE_APR"
  + APRINCLUDEDIR="-I`$APXS -q APR_INCLUDEDIR`"
  + APXSCFLAGS="`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS` 
-DHAVE_APR ${APRINCLUDEDIR}"
APXSCPPFLAGS="`${APXS} -q EXTRA_CPPFLAGS`"
   APACHE_CONFIG_VARS=${apache_dir}/build/config_vars.mk
   LIBTOOL=`$APXS -q LIBTOOL`
  
  
  

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

Re: [Fwd: Re: Restarted Tomcat (again)]

[jean-frederic clere]

Henri Gomez wrote:
FYI :





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


try {
   ...
} catchc (OutOfMemoryException e) {
   e.printStackTrace();
   System.exit(99);
}
exit! Could we do something else?

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

Re: TOMCAT-fix for os/390??

[jean-frederic clere]

Anna Fuhrmann wrote:
Hi all,
like  a good girl I have been using the user-mailing-list up to now to search for
user experience installing tomcat on os390.
Most (if not all) contributions are in the form "has anyone successfully installed
tomcat on os390?" From some other I got partly valuable ideas. 
Not on os390 but on BS2000.

I have been TRYING to get tomcat run on os390 in the last couple of days.
Done everything I could - everything seems to be allright up to this pont: tomcat IS running at last
without any serious signs of disbehaviour - no error messages at all, xml's behaving well. But if we connect to
localhost:tomcatport/index.jsp  (or wahtever else for that matter), the browser does not show
anything. Doing the same with a perl script shows that the server is ansering and is supplying the 
requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID
(i.e.: ebcdic) LINE SEPARATOR. So thats the reason why.
"\r\n".getBytes() :-(
I have patched http11/src/java/org/apache/coyote/http11/Constants.java to fix this.
Today I tried to identify the .java-file giving us the header (looking for \r\n) . I thought I found it, 
by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. Newline
in ebcdic). 

What I would like to know: Is there any kind of patch for os/390? Do you have any 
suggestions?
Is anybody working on it? What should I do?
On BS2000 I have the requirement that all the "text" or source files have to be 
in EBCDIC.
So I have had to patch the DefaultServer to display the html pages and I have 
added our encoding to xerces and update every xml files to have the 
corresponding encoding header. My Tomcat is able to serv static pages and some 
of the servlet are working (ResourceBundle problems). JSP is broken (Content in 
EBCDIC).

I want to have this beast running.
Me too :-)

PLEASE.

We have os390 2.10
IBM-JDK 1.3
tomcat 4.1.27
Anna Fuhrmann   




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