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

2005-09-29 Thread Costin Manolache

Remy Maucherat wrote:

Jan Luehe wrote:

As a reminder, CVS shound't be used anymore.


I commited a bunch of small changes, don't know how easy it'll be to get 
them in after the switch to svn. Let me know if there's a problem, I can 
roll them back.


BTW - I had some of the changes in IntrospectionUtils in my workspace as 
well, so I don't have to commit that :-)


Costin


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



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

2005-09-28 Thread Remy Maucherat

[EMAIL PROTECTED] wrote:

  +/*
  + * Clear the IntrospectionUtils cache.
  + *
  + * Implementation note:
  + * Any reference to IntrospectionUtils which may cause the static
  + * initalizer of that class to be invoked must occur prior to setting
  + * the started flag to FALSE, because the static initializer of
  + * IntrospectionUtils makes a call to
  + * org.apache.commons.logging.LogFactory.getLog(), which ultimately
  + * calls the loadClass() method of the thread context classloader,
  + * which is the same as this classloader, whose impl throws a
  + * ThreadDeath if the started flag has been set to FALSE.
  + */
  +IntrospectionUtils.clear();
  +


This commit does not make sense to me. The static initializer is called 
when loading the class, and obviously the webapp CL is not going to load 
IntrospectionUtils.


You should forget that the CVS exists, as we're in the middle of 
migrating to SVN (of course, losing that commit will not be a problem).


Rémy

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



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

2005-09-28 Thread Jan Luehe
Remy,

Remy Maucherat wrote On 09/28/05 03:12,:
 [EMAIL PROTECTED] wrote:
 
  +/*
  + * Clear the IntrospectionUtils cache.
  + *
  + * Implementation note:
  + * Any reference to IntrospectionUtils which may cause the static
  + * initalizer of that class to be invoked must occur prior to 
 setting
  + * the started flag to FALSE, because the static initializer of
  + * IntrospectionUtils makes a call to
  + * org.apache.commons.logging.LogFactory.getLog(), which ultimately
  + * calls the loadClass() method of the thread context classloader,
  + * which is the same as this classloader, whose impl throws a
  + * ThreadDeath if the started flag has been set to FALSE.
  + */
  +IntrospectionUtils.clear();
  +
 
 
 This commit does not make sense to me. The static initializer is called 
 when loading the class, and obviously the webapp CL is not going to load 
 IntrospectionUtils.

This code in IntrospectionUtils.java:

private static org.apache.commons.logging.Log log=
org.apache.commons.logging.LogFactory.getLog(
IntrospectionUtils.class );

will cause LogFactoryImpl.getLogConstructor() to be called, which
in turn will invoke LogFactoryImpl.loadClass(String name), which is
implemented as follows:

private static Class loadClass( final String name )
throws ClassNotFoundException
{
Object result = AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
ClassLoader threadCL = getContextClassLoader();
if (threadCL != null) {
try {
return threadCL.loadClass(name);
} catch( ClassNotFoundException ex ) {
// ignore
}
}
try {
return Class.forName( name );
} catch (ClassNotFoundException e) {
return e;
}
}
});

if (result instanceof Class)
return (Class)result;

throw (ClassNotFoundException)result;
}

Notice the use of the thread context classloader (to load the class
with the given name), which is the same as the WebappClassLoader.

WebappClassLoader.loadClass() has this:

// Don't load classes if class loader is stopped
if (!started) {
log.info(sm.getString(webappClassLoader.stopped));
throw new ThreadDeath();
}

We have seen the ThreadDeath in our callstacks, hence this fix.

Jan


 You should forget that the CVS exists, as we're in the middle of 
 migrating to SVN (of course, losing that commit will not be a problem).
 
 Rémy
 
 -
 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

2005-09-28 Thread Remy Maucherat

Jan Luehe wrote:

We have seen the ThreadDeath in our callstacks, hence this fix.


Nobody is reading what I am writing anymore ...

I wrote:
The static initializer is called when loading the class, and obviously 
the webapp CL is not going to load IntrospectionUtils.


IntrospectionUtils will be loaded once, and its static initializer run 
once. So I am ok with your fix, but I don't understand how it can occur 
in regular Tomcat.


The big comment block is quite pointless, as it tries to be 
informational, but doesn't correspond to reality (I am personally 
against this kind of commit message duplication comment).


As a reminder, CVS shound't be used anymore.

Rémy

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



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

2005-09-28 Thread Jan Luehe
Remy,

Remy Maucherat wrote On 09/28/05 10:18,:
 Jan Luehe wrote:
 
We have seen the ThreadDeath in our callstacks, hence this fix.
 
 
 Nobody is reading what I am writing anymore ...

No, I did.

 I wrote:
 The static initializer is called when loading the class, and obviously 
 the webapp CL is not going to load IntrospectionUtils.
 
 IntrospectionUtils will be loaded once, and its static initializer run 
 once.

Yes, but with lazy resolution, it will be loaded when the
IntrospectionUtils symbol is first encountered, which may
be inside WebappClassLoader.stop().

IntrospectionUtils' static initializer will cause an invocation of
loadClass() on the thread's context classloader, which corresponds to
the WebappClassLoader, whose loadClass() throws ThreadDeath when
its started flag has been set to FALSE.

Therefore, we must avoid referencing IntrospectionUtils in
WebappClassLoader.stop() after the started flag has been
set to FALSE.

 So I am ok with your fix, but I don't understand how it can occur 
 in regular Tomcat.

It's probably not occurring in standalone Tomcat, but only
in embedded Tomcat. In standalone Tomcat, IntrospectionUtils is
probably getting resolved (and its static initializer invoked)
prior to calling WebappClassLoader.stop(),
whereas in embedded mode, IntrospectionUtils is first referenced
and loaded by WebappClassLoader.stop().

 The big comment block is quite pointless, as it tries to be 
 informational, but doesn't correspond to reality (I am personally 
 against this kind of commit message duplication comment).

Sure, I just thought this line might be an easy candidate for
being moved around if there was no comment.

 As a reminder, CVS shound't be used anymore.

Yes.


Jan

 
 Rémy
 
 -
 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

2005-09-28 Thread Remy Maucherat

Jan Luehe wrote:

No, I did.


Cool, there's one, at least :)


Yes, but with lazy resolution, it will be loaded when the
IntrospectionUtils symbol is first encountered, which may
be inside WebappClassLoader.stop().


Normally, it's used by plenty of things, like the digester. Who knows 
anyway, I find the classloading behavior to be weird sometimes.


So I am ok with your fix, but I don't understand how it can occur 
in regular Tomcat.


It's probably not occurring in standalone Tomcat, but only
in embedded Tomcat. In standalone Tomcat, IntrospectionUtils is
probably getting resolved (and its static initializer invoked)
prior to calling WebappClassLoader.stop(),
whereas in embedded mode, IntrospectionUtils is first referenced
and loaded by WebappClassLoader.stop().

The big comment block is quite pointless, as it tries to be 
informational, but doesn't correspond to reality (I am personally 
against this kind of commit message duplication comment).


Sure, I just thought this line might be an easy candidate for
being moved around if there was no comment.


Stuff won't get moved around for no reason ;)

It would actually be good to move the 3 cleanup calls to 
StandardContext.stop.


Rémy

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



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

2004-07-03 Thread Bill Barker

- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, July 03, 2004 11:50 AM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java


===
   RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loa
der/WebappClassLoader.java,v
   retrieving revision 1.36
   retrieving revision 1.37
   diff -u -r1.36 -r1.37
   --- WebappClassLoader.java 25 Jun 2004 23:56:25 - 1.36
   +++ WebappClassLoader.java 3 Jul 2004 18:50:10 - 1.37
   @@ -1886,8 +1886,12 @@
 */
protected boolean isPackageSealed(String name, Manifest man) {

   -String path = name + /;
   -Attributes attr = man.getAttributes(path);
   +StringBuffer buf = new StringBuffer(name);
   +for (int i=0;ibuf.length();i++) {
   +if (buf.charAt(i)=='.') buf.setCharAt(i,'/');
   +}
   +buf.append('/');
   +Attributes attr = man.getAttributes(buf.toString());
String sealed = null;
if (attr != null) {
sealed = attr.getValue(Name.SEALED);



It's not a big deal, but wouldn't it be cleaner to do:
String path = name.replace('.', '/') + /;




 -
 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

2004-07-03 Thread Mark Thomas
From: Bill Barker [mailto:[EMAIL PROTECTED] 
 From: [EMAIL PROTECTED]
 
 ===
RCS file:
 /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apach
e/catalina/loa
 der/WebappClassLoader.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- WebappClassLoader.java 25 Jun 2004 23:56:25 - 1.36
+++ WebappClassLoader.java 3 Jul 2004 18:50:10 - 1.37
@@ -1886,8 +1886,12 @@
  */
 protected boolean isPackageSealed(String name, 
 Manifest man) {
 
-String path = name + /;
-Attributes attr = man.getAttributes(path);
+StringBuffer buf = new StringBuffer(name);
+for (int i=0;ibuf.length();i++) {
+if (buf.charAt(i)=='.') buf.setCharAt(i,'/');
+}
+buf.append('/');
+Attributes attr = man.getAttributes(buf.toString());
 String sealed = null;
 if (attr != null) {
 sealed = attr.getValue(Name.SEALED);
 
 It's not a big deal, but wouldn't it be cleaner to do:
 String path = name.replace('.', '/') + /;

Fair point. I'll make the change.



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



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

2003-09-07 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

remm2003/09/06 10:49:31

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
This patch isn't portable to 4.1.x, because the issue there isn't the 
same (it would is Jasper from 4.1.x used commons-logging, but thankfully 
it does not, so the headache level is lower).

I'm suspecting what causes bug 22701 in TC 4.1.x is that the context 
classloader isn't properly reset in the StandardHostValve (I did that on 
purpose originally, thinking it was useless; maybe not ;-) ).

Remy



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


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

2003-02-03 Thread Bill Barker

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 11:24 PM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java


 billbarker2003/02/03 23:24:22

   Modified:catalina/src/share/org/apache/catalina/loader
 WebappClassLoader.java
   Log:
   Finally regain the ability to build under 1.3.x

   Submitted By: Tim Funk [EMAIL PROTECTED]

Sorry for the typo:  It should be [EMAIL PROTECTED]



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