Gary, thank you for your response. I believe - the more ideas, the better.
I agree that it would be better to have a unified resource loading strategy, but Joe says it's not so easy... Now regarding my 1st question. I suspect that if we do not split step 3 into 3a and 3b, and if step 2 is not successful due to 1.1 platform, then step 3 is likely to fail also if Xalan is not available to the system classloader (say, is not on the CLASSPATH). So it seems more safe to split. But my understanding of the matter is very shallow, and if you could give a more detailed analysis (as you seem to have promised ;-) - it would be great. Regarding my 2nd question about resource name prefixing. It seems I was wrong. My fears might be appropriate if we used Class.getResource() instead of ClassLoader.getResource(), but it is not the case. So, looking forward to your analysis... Regards, Sergey ----- Original Message ----- From: "Gary L Peskin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 18, 2002 9:53 PM Subject: RE: New Xalan not playing well with Tomcat 4.0? > 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 > > > >
