Sergey -- Pardon me for jumping in to your question to Myriam but I can answer some of these issues.
I think the answer to (1) is that we need to have a Xalan-wide classloader strategy and we should implement that in all of the places that we use classloaders. I think that I saw an email to the effect that Myriam, Scott, Joe, etc. have discussed this and may be moving in that direction. I either didn't read or don't remember what that strategy was. If it wasn't articulated here, perhaps Myriam or someone could post it. If it hasn't been formed, I could suggest one and we could discuss. The current strategy embodied in Encodings is: 1. If there is a system property called "org.apache.xalan.serialize.encodings", get the value of that property. Try to make that value into a URL. If it works, use that URL as the URL of the encodings file. Otherwise, if we are running under Java 2, go to step 2. If we are running under JDK 1.1.x, go to step 3. 2. We are running under Java 2, try to find the file called org/apache/xalan/serialize/Encodings.properties using the ContextClassLoader for the current thread. If it is found, use it. Otherwise, proceed to step 3. 3. We are running under JDK 1.1.x -or- we couldn't find the file using the ContextClassLoader for the current thread. In this case, try to find the file called org/apache/xalan/serialize/Encodings.properties using the system ClassLoader. Your question (1) says that maybe we should modify this so that step 3 becomes steps 3a and 3b: 3a. We are running under JDK 1.1.x -or- we couldn't find the file using the ContextClassLoader for the current thread. In this case, try to find the file called org/apache/xalan/serialize/Encodings.properties using the ClassLoader that was used to load the Encodings class itself. 3b. Try to find the file called org/apache/xalan/serialize/Encodings.properties using the system ClassLoader. Options 3a/3b will behave different than option 3 in cases where Xalan resides in the bootclasspath or lib/ext folder. I don't have the time at the moment to work out the different scenarios, including running as an extension and running from inside a servlet engine that does or doesn't set the current ContextClassLoader but I'd be happy to do that. With regard to question (2), this is a different question. When Xalan supplies the Encodings.properties file, it supplies it in location org/apache/xalan/serialize Where a particular ClassLoader will find this depends on the class loading strategy and the "classpath" used by that ClassLoader. I don't see where we'll prepend the package name twice as you say. But it does bring up the question as to whether a user overriding our Encodings.properties file wants to go to the trouble of placing his/her file in the same package that we use. Perhaps we should look for Encodings.properties first in our package and then in the default package. As I said, this is a different issue and one that also merits discussion. BTW, the OS/390 (zSeries) people have solved the problem of the appropriate encoding for standalone properties files. As some of you may recall, the problem was that our file within the .jar is in ASCII whereas the platform default encoding is EBCDIC so any freestanding file created by a user would likely be in EBCDIC. The z/OS JVM people have solved this in JDK 1.3.1 r11. They simply look at the first few lines of the file and set the encoding internally to the appropriate value!!! So this is not a problem that Xalan needs to deal with anymore. Gary > -----Original Message----- > From: Ushakov, Sergey N [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 18, 2002 8:56 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; Gary L Peskin > Subject: Re: New Xalan not playing well with Tomcat 4.0? > > > [moved at last from [EMAIL PROTECTED] :) ] > > Myriam, > > two important things happened to me today :) > > 1) I got new Gary's message from [EMAIL PROTECTED] > and re-read Joe's comments of 2002-06-04 regarding context > class loaders and compatibility issues; > 2) I had a look at the new version of > org.apache.xalan.serialize.Encodings > you've submitted to the CVS. > > So I got two new questions: > 1) What is your opinion, maybe we need to retain the fragment > dealing with ordinary class-specific class loader in order to > have 1.1.8 compatibility? Just before calling > ClassLoader.getSystemResource() as the last resort... > Something like this: > > // ... dealing with context class loader, reflection, etc. ... // ... > if (url == null) { > ClassLoader cl = Encodings.class.getClassLoader(); > if (cl != null) { > url = cl.getResource(ENCODINGS_FILE); > } > if (url == null) > url = ClassLoader.getSystemResource(ENCODINGS_FILE); > // ... > > 2) Are you sure that having ENCODINGS_FILE with package name > prepended is safe for using with non-system class loaders - > those except static > ClassLoader.getSystemResource() ? I am not a smart guy in > class loading :) , I just have re-read the Sun guidelines at > http://java.sun.com/j2se/1.3/docs/guide/resources/resources.ht > ml and got an impression that package name is expected to be > prepended only for static > ClassLoader.getSystemResource() . Can't it happen that > package name gets prepended twice while resource name > resolving in our case? I'm also not sure whether it should > be better formatted as relative or absolute for the system > class loader... > > Regards, > Sergey > > > ----- Original Message ----- > From: "Gary L Peskin" <[EMAIL PROTECTED]> > To: "'Ushakov, Sergey N'" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, June 18, 2002 8:03 AM > Subject: RE: New Xalan not playing well with Tomcat 4.0? > > > > Sergey -- > > > > I've been out of town. Did you ever get a satisfactory answer to > > this? > > > > Gary > > > > > -----Original Message----- > > > From: Ushakov, Sergey N [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, June 03, 2002 10:00 PM > > > To: [EMAIL PROTECTED] > > > Cc: Gary L Peskin > > > Subject: Re: New Xalan not playing well with Tomcat 4.0? > > > > > > > > > Gary, > > > > > > I've looked into Xalan sources and saw that context class loaders > > > are widely used. But I could not catch the idea beyond it. > > > > > > Isn't it expected that if a standard Xalan resource is > required then > > > it is loaded from the Xalan bundle? Is a context class loader > > > necessary for it? > > > > > > Sorry if I'm asking something obvious. > > > > > > Regards, > > > Sergey > > > > > > > > > > > > ----- Original Message ----- > > > From: "Gary L Peskin" <[EMAIL PROTECTED]> > > > To: "'Ushakov, Sergey N'" <[EMAIL PROTECTED]>; > > > <[EMAIL PROTECTED]> > > > Cc: "'Bryan Kearney'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > Sent: Monday, June 03, 2002 5:34 PM > > > Subject: RE: New Xalan not playing well with Tomcat 4.0? > > > > > > > > > > Miriam -- > > > > > > > > A problem here (which is still here) is that the > classloader being > > > > obtained is the one used to load the Encodings class > and not the > > > > ContextClassLoader. Unfortunately, I'm travelling and > > > don't have time > > > > to clean this up. Can you or Joe take care of it? > > > > > > > > Gary > > > > > > > > > > [...] > > > > > > > >
