You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Ushakov, Sergey N" <us...@int.com.ru> on 2002/06/18 17:56:21 UTC
Re: New Xalan not playing well with Tomcat 4.0?
[moved at last from xalan-j-users@xml.apache.org :) ]
Myriam,
two important things happened to me today :)
1) I got new Gary's message from xalan-j-users@xml.apache.org 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.html 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" <ga...@firstech.com>
To: "'Ushakov, Sergey N'" <us...@int.com.ru>;
<xa...@xml.apache.org>
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:ushakov@int.com.ru]
> > Sent: Monday, June 03, 2002 10:00 PM
> > To: xalan-j-users@xml.apache.org
> > 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" <ga...@firstech.com>
> > To: "'Ushakov, Sergey N'" <us...@int.com.ru>;
> > <xa...@xml.apache.org>
> > Cc: "'Bryan Kearney'" <bk...@avolent.com>; <mm...@apache.org>
> > 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
> > >
> >
> > [...]
> >
>
>
RE: New Xalan not playing well with Tomcat 4.0?
Posted by Gary L Peskin <ga...@firstech.com>.
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:ushakov@int.com.ru]
> Sent: Tuesday, June 18, 2002 3:57 PM
> To: xalan-dev@xml.apache.org
> Cc: Gary L Peskin; Joseph Kesselman; myriam_midy@us.ibm.com
> 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" <ga...@firstech.com>
> To: <xa...@xml.apache.org>
> 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:ushakov@int.com.ru]
> > > Sent: Tuesday, June 18, 2002 8:56 AM
> > > To: xalan-dev@xml.apache.org
> > > Cc: myriam_midy@us.ibm.com; Gary L Peskin
> > > Subject: Re: New Xalan not playing well with Tomcat 4.0?
> > >
> > >
> > > [moved at last from xalan-j-users@xml.apache.org :) ]
> > >
> > > Myriam,
> > >
> > > two important things happened to me today :)
> > >
> > > 1) I got new Gary's message from xalan-j-users@xml.apache.org 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
> > >
> > >
>
Re: New Xalan not playing well with Tomcat 4.0?
Posted by "Ushakov, Sergey N" <us...@int.com.ru>.
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" <ga...@firstech.com>
To: <xa...@xml.apache.org>
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:ushakov@int.com.ru]
> > Sent: Tuesday, June 18, 2002 8:56 AM
> > To: xalan-dev@xml.apache.org
> > Cc: myriam_midy@us.ibm.com; Gary L Peskin
> > Subject: Re: New Xalan not playing well with Tomcat 4.0?
> >
> >
> > [moved at last from xalan-j-users@xml.apache.org :) ]
> >
> > Myriam,
> >
> > two important things happened to me today :)
> >
> > 1) I got new Gary's message from xalan-j-users@xml.apache.org
> > 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
> >
> >
RE: New Xalan not playing well with Tomcat 4.0?
Posted by Gary L Peskin <ga...@firstech.com>.
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:ushakov@int.com.ru]
> Sent: Tuesday, June 18, 2002 8:56 AM
> To: xalan-dev@xml.apache.org
> Cc: myriam_midy@us.ibm.com; Gary L Peskin
> Subject: Re: New Xalan not playing well with Tomcat 4.0?
>
>
> [moved at last from xalan-j-users@xml.apache.org :) ]
>
> Myriam,
>
> two important things happened to me today :)
>
> 1) I got new Gary's message from xalan-j-users@xml.apache.org
> 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" <ga...@firstech.com>
> To: "'Ushakov, Sergey N'" <us...@int.com.ru>;
> <xa...@xml.apache.org>
> 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:ushakov@int.com.ru]
> > > Sent: Monday, June 03, 2002 10:00 PM
> > > To: xalan-j-users@xml.apache.org
> > > 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" <ga...@firstech.com>
> > > To: "'Ushakov, Sergey N'" <us...@int.com.ru>;
> > > <xa...@xml.apache.org>
> > > Cc: "'Bryan Kearney'" <bk...@avolent.com>; <mm...@apache.org>
> > > 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
> > > >
> > >
> > > [...]
> > >
> >
> >
>