Thanks, Sergey. I've talked to Scott about this and I think a discussion will be commencing soon.
Gary > -----Original Message----- > From: Ushakov, Sergey N [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 18, 2002 3:57 PM > To: [EMAIL PROTECTED] > Cc: Gary L Peskin; Joseph Kesselman; [EMAIL PROTECTED] > Subject: Re: New Xalan not playing well with Tomcat 4.0? > > > 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 > > > > > > >
