Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

Ryan Scharer
Hey folks,

I'm not sure if this is a bug or not, but I can't find any relevant
information in the spec to suggest the behavior is expected.

There's a web-fragment in my classpath that I'd like to skip. The only way
to accomplish this that I know of is to put an <absolute-ordering> stanza
in my web.xml and omit an <others/>. Though this has the desired effect of
skipping the web-fragment I don't want, it has the very negative side
effect that my ServletContainerInitializer doesn't get handed all instances
of WebApplicationInitializer anymore, despite its @HandlesTypes annotation.
If I add the <others/>, classpath scanning works fine, but the undesired
web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat
releases.


This begs two questions:

   1. Why does specifying an <absolute-ordering> without an <others/> kill
   classpath scanning, or at least the part of Tomcat responsible for finding
   types specified by @HandlesTypes and giving it to interested parties?
   2. Is there an alternate way to skip a web-fragment, short of ripping it
   out of the jar, which I really don't want to do?

Thanks!

-Ryan
Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ryan,

On 2/13/15 12:59 PM, Ryan Scharer wrote:

> I'm not sure if this is a bug or not, but I can't find any relevant
>  information in the spec to suggest the behavior is expected.
>
> There's a web-fragment in my classpath that I'd like to skip. The
> only way to accomplish this that I know of is to put an
> <absolute-ordering> stanza in my web.xml and omit an <others/>.
> Though this has the desired effect of skipping the web-fragment I
> don't want, it has the very negative side effect that my
> ServletContainerInitializer doesn't get handed all instances of
> WebApplicationInitializer anymore, despite its @HandlesTypes
> annotation. If I add the <others/>, classpath scanning works fine,
> but the undesired web-fragment comes back. I've tested this in the
> latest 7.x and 8.x Tomcat releases.
>
> This begs two questions:
>
> 1. Why does specifying an <absolute-ordering> without an <others/>
> kill classpath scanning, or at least the part of Tomcat
> responsible for finding types specified by @HandlesTypes and giving
> it to interested parties? 2. Is there an alternate way to skip a
> web-fragment, short of ripping it out of the jar, which I really
> don't want to do?

It's unclear to me why <absolute-ordering> affects JAR scanning...
absolute-ordering should affect only the processing of web-fragments.
The Tomcat documentation for absolute-ordering makes it sounds like
you have to mention a JAR name while the spec documentation makes it
seem like you need to use the <name> element from web-fragments that
are detected in JAR files.

The whole thing is a can of worms, honestly.

As for your inability to skip a web-fragment... that seems
straightforward to me: if you have <others/> specified, then
"everything else" will be processed in that order, including the
web-fragment you don't want. There does not seem to be a way to
blacklist a web-fragment short of completely removing it from your
project's libraries.

But the fact that the lack of <others> causes Tomcat to fail to do JAR
scanning is surprising to me. I tend to prefer explicit configuration
over all this scanning-related magic so I'm afraid I don't have any
experience with this kind of thing. In fact, it's this kind of
foolishness that makes me stick with explicitly-specified
configurations instead of magic ones. Good luck figuring out how the
magic works / is supposed to work!

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy
6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw
MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O
a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5
neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd
BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d
g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu
NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar
UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B
wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1
FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B
5Uolv99PqOrAJOE+F/NV
=sw5S
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

Ryan Scharer
Chris,

I share your misgivings about magic, though if it exhibits well-documented
and predictable behavior I usually just shrug and go along with it. Sadly
that doesn't seem to be the case here. I'll set aside some time to step
through the Tomcat code to try to figure this out, though in the meantime
my best bet may be to repackage the 3rd party jar minus its web-fragment.

-R

On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz <
[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Ryan,
>
> On 2/13/15 12:59 PM, Ryan Scharer wrote:
> > I'm not sure if this is a bug or not, but I can't find any relevant
> >  information in the spec to suggest the behavior is expected.
> >
> > There's a web-fragment in my classpath that I'd like to skip. The
> > only way to accomplish this that I know of is to put an
> > <absolute-ordering> stanza in my web.xml and omit an <others/>.
> > Though this has the desired effect of skipping the web-fragment I
> > don't want, it has the very negative side effect that my
> > ServletContainerInitializer doesn't get handed all instances of
> > WebApplicationInitializer anymore, despite its @HandlesTypes
> > annotation. If I add the <others/>, classpath scanning works fine,
> > but the undesired web-fragment comes back. I've tested this in the
> > latest 7.x and 8.x Tomcat releases.
> >
> > This begs two questions:
> >
> > 1. Why does specifying an <absolute-ordering> without an <others/>
> > kill classpath scanning, or at least the part of Tomcat
> > responsible for finding types specified by @HandlesTypes and giving
> > it to interested parties? 2. Is there an alternate way to skip a
> > web-fragment, short of ripping it out of the jar, which I really
> > don't want to do?
>
> It's unclear to me why <absolute-ordering> affects JAR scanning...
> absolute-ordering should affect only the processing of web-fragments.
> The Tomcat documentation for absolute-ordering makes it sounds like
> you have to mention a JAR name while the spec documentation makes it
> seem like you need to use the <name> element from web-fragments that
> are detected in JAR files.
>
> The whole thing is a can of worms, honestly.
>
> As for your inability to skip a web-fragment... that seems
> straightforward to me: if you have <others/> specified, then
> "everything else" will be processed in that order, including the
> web-fragment you don't want. There does not seem to be a way to
> blacklist a web-fragment short of completely removing it from your
> project's libraries.
>
> But the fact that the lack of <others> causes Tomcat to fail to do JAR
> scanning is surprising to me. I tend to prefer explicit configuration
> over all this scanning-related magic so I'm afraid I don't have any
> experience with this kind of thing. In fact, it's this kind of
> foolishness that makes me stick with explicitly-specified
> configurations instead of magic ones. Good luck figuring out how the
> magic works / is supposed to work!
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy
> 6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw
> MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O
> a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5
> neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd
> BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d
> g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu
> NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar
> UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B
> wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1
> FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B
> 5Uolv99PqOrAJOE+F/NV
> =sw5S
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

markt
In reply to this post by Ryan Scharer
On 13/02/2015 17:59, Ryan Scharer wrote:

> Hey folks,
>
> I'm not sure if this is a bug or not, but I can't find any relevant
> information in the spec to suggest the behavior is expected.
>
> There's a web-fragment in my classpath that I'd like to skip. The only way
> to accomplish this that I know of is to put an <absolute-ordering> stanza
> in my web.xml and omit an <others/>. Though this has the desired effect of
> skipping the web-fragment I don't want, it has the very negative side
> effect that my ServletContainerInitializer doesn't get handed all instances
> of WebApplicationInitializer anymore, despite its @HandlesTypes annotation.
> If I add the <others/>, classpath scanning works fine, but the undesired
> web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat
> releases.
>
>
> This begs two questions:
>
>    1. Why does specifying an <absolute-ordering> without an <others/> kill
>    classpath scanning, or at least the part of Tomcat responsible for finding
>    types specified by @HandlesTypes and giving it to interested parties?

Because the Servlet spec says so.

Servlet 3.1, section 8.2.2, 1. d. (page 8-73)

"... Irrespective of the setting of metadata-complete, jars excluded by
<absolute-ordering> elements are not scanned for classes to be handled
by any ServletContainerInitializer."

>    2. Is there an alternate way to skip a web-fragment, short of ripping it
>    out of the jar, which I really don't want to do?

There is no way I am aware of that allows you to skip the
web-fragment.xml but still scan the JAR for SCIs and @HandlesTypes
matches to those SCIs.

Depending on what is in the web-frgament.xml you might be able to put
entries in the main web.xml to override them.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

markt
In reply to this post by Ryan Scharer
On 13/02/2015 18:49, Ryan Scharer wrote:
> Chris,
>
> I share your misgivings about magic, though if it exhibits well-documented
> and predictable behavior I usually just shrug and go along with it. Sadly
> that doesn't seem to be the case here.

It is documented but I'd agree it could be better documented.

 I'll set aside some time to step
> through the Tomcat code to try to figure this out,

Save yourself the effort and read this from line ~1085.

http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate

Mark

> though in the meantime
> my best bet may be to repackage the 3rd party jar minus its web-fragment.
>
> -R
>
> On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz <
> [hidden email]> wrote:
>
> Ryan,
>
> On 2/13/15 12:59 PM, Ryan Scharer wrote:
>>>> I'm not sure if this is a bug or not, but I can't find any relevant
>>>>  information in the spec to suggest the behavior is expected.
>>>>
>>>> There's a web-fragment in my classpath that I'd like to skip. The
>>>> only way to accomplish this that I know of is to put an
>>>> <absolute-ordering> stanza in my web.xml and omit an <others/>.
>>>> Though this has the desired effect of skipping the web-fragment I
>>>> don't want, it has the very negative side effect that my
>>>> ServletContainerInitializer doesn't get handed all instances of
>>>> WebApplicationInitializer anymore, despite its @HandlesTypes
>>>> annotation. If I add the <others/>, classpath scanning works fine,
>>>> but the undesired web-fragment comes back. I've tested this in the
>>>> latest 7.x and 8.x Tomcat releases.
>>>>
>>>> This begs two questions:
>>>>
>>>> 1. Why does specifying an <absolute-ordering> without an <others/>
>>>> kill classpath scanning, or at least the part of Tomcat
>>>> responsible for finding types specified by @HandlesTypes and giving
>>>> it to interested parties? 2. Is there an alternate way to skip a
>>>> web-fragment, short of ripping it out of the jar, which I really
>>>> don't want to do?
>
> It's unclear to me why <absolute-ordering> affects JAR scanning...
> absolute-ordering should affect only the processing of web-fragments.
> The Tomcat documentation for absolute-ordering makes it sounds like
> you have to mention a JAR name while the spec documentation makes it
> seem like you need to use the <name> element from web-fragments that
> are detected in JAR files.
>
> The whole thing is a can of worms, honestly.
>
> As for your inability to skip a web-fragment... that seems
> straightforward to me: if you have <others/> specified, then
> "everything else" will be processed in that order, including the
> web-fragment you don't want. There does not seem to be a way to
> blacklist a web-fragment short of completely removing it from your
> project's libraries.
>
> But the fact that the lack of <others> causes Tomcat to fail to do JAR
> scanning is surprising to me. I tend to prefer explicit configuration
> over all this scanning-related magic so I'm afraid I don't have any
> experience with this kind of thing. In fact, it's this kind of
> foolishness that makes me stick with explicitly-specified
> configurations instead of magic ones. Good luck figuring out how the
> magic works / is supposed to work!
>
> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

Ryan Scharer
Thanks! That comment was an enormous help. I was able to achieve what I
wanted just by setting metadata-complete to true. I had previously assumed
that that would disable jar scanning. Instead it simply disables
web-fragment scanning.

What still confuses me is why the only mechanism provided by the spec to
enable or disable scanning of a particular jar is by referring to the
<name> of a related web-fragment. What about jars that have annotations but
no web-fragment? Likely I'm still misunderstanding something fundamental.

Anyway, I now have the functionality I need. Thanks again for the
assistance.

-R

On Fri, Feb 13, 2015 at 2:54 PM, Mark Thomas <[hidden email]> wrote:

> On 13/02/2015 18:49, Ryan Scharer wrote:
> > Chris,
> >
> > I share your misgivings about magic, though if it exhibits
> well-documented
> > and predictable behavior I usually just shrug and go along with it. Sadly
> > that doesn't seem to be the case here.
>
> It is documented but I'd agree it could be better documented.
>
>  I'll set aside some time to step
> > through the Tomcat code to try to figure this out,
>
> Save yourself the effort and read this from line ~1085.
>
>
> http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate
>
> Mark
>
> > though in the meantime
> > my best bet may be to repackage the 3rd party jar minus its web-fragment.
> >
> > -R
> >
> > On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz <
> > [hidden email]> wrote:
> >
> > Ryan,
> >
> > On 2/13/15 12:59 PM, Ryan Scharer wrote:
> >>>> I'm not sure if this is a bug or not, but I can't find any relevant
> >>>>  information in the spec to suggest the behavior is expected.
> >>>>
> >>>> There's a web-fragment in my classpath that I'd like to skip. The
> >>>> only way to accomplish this that I know of is to put an
> >>>> <absolute-ordering> stanza in my web.xml and omit an <others/>.
> >>>> Though this has the desired effect of skipping the web-fragment I
> >>>> don't want, it has the very negative side effect that my
> >>>> ServletContainerInitializer doesn't get handed all instances of
> >>>> WebApplicationInitializer anymore, despite its @HandlesTypes
> >>>> annotation. If I add the <others/>, classpath scanning works fine,
> >>>> but the undesired web-fragment comes back. I've tested this in the
> >>>> latest 7.x and 8.x Tomcat releases.
> >>>>
> >>>> This begs two questions:
> >>>>
> >>>> 1. Why does specifying an <absolute-ordering> without an <others/>
> >>>> kill classpath scanning, or at least the part of Tomcat
> >>>> responsible for finding types specified by @HandlesTypes and giving
> >>>> it to interested parties? 2. Is there an alternate way to skip a
> >>>> web-fragment, short of ripping it out of the jar, which I really
> >>>> don't want to do?
> >
> > It's unclear to me why <absolute-ordering> affects JAR scanning...
> > absolute-ordering should affect only the processing of web-fragments.
> > The Tomcat documentation for absolute-ordering makes it sounds like
> > you have to mention a JAR name while the spec documentation makes it
> > seem like you need to use the <name> element from web-fragments that
> > are detected in JAR files.
> >
> > The whole thing is a can of worms, honestly.
> >
> > As for your inability to skip a web-fragment... that seems
> > straightforward to me: if you have <others/> specified, then
> > "everything else" will be processed in that order, including the
> > web-fragment you don't want. There does not seem to be a way to
> > blacklist a web-fragment short of completely removing it from your
> > project's libraries.
> >
> > But the fact that the lack of <others> causes Tomcat to fail to do JAR
> > scanning is surprising to me. I tend to prefer explicit configuration
> > over all this scanning-related magic so I'm afraid I don't have any
> > experience with this kind of thing. In fact, it's this kind of
> > foolishness that makes me stick with explicitly-specified
> > configurations instead of magic ones. Good luck figuring out how the
> > magic works / is supposed to work!
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

markt
On 15/02/2015 17:42, Ryan Scharer wrote:
> Thanks! That comment was an enormous help. I was able to achieve what I
> wanted just by setting metadata-complete to true. I had previously assumed
> that that would disable jar scanning. Instead it simply disables
> web-fragment scanning.
>
> What still confuses me is why the only mechanism provided by the spec to
> enable or disable scanning of a particular jar is by referring to the
> <name> of a related web-fragment. What about jars that have annotations but
> no web-fragment?

Tomcat will give these a name equal to the name of the JAR file so you
can use it in ordering. That is a Tomcat specific feature.

> Likely I'm still misunderstanding something fundamental.

Probably not. There are some functionality gaps in the way pluggability
was designed and this is essentially one of them.

> Anyway, I now have the functionality I need. Thanks again for the
> assistance.

Great. That is the main thing.

Mark


>
> -R
>
> On Fri, Feb 13, 2015 at 2:54 PM, Mark Thomas <[hidden email]> wrote:
>
>> On 13/02/2015 18:49, Ryan Scharer wrote:
>>> Chris,
>>>
>>> I share your misgivings about magic, though if it exhibits
>> well-documented
>>> and predictable behavior I usually just shrug and go along with it. Sadly
>>> that doesn't seem to be the case here.
>>
>> It is documented but I'd agree it could be better documented.
>>
>>  I'll set aside some time to step
>>> through the Tomcat code to try to figure this out,
>>
>> Save yourself the effort and read this from line ~1085.
>>
>>
>> http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate
>>
>> Mark
>>
>>> though in the meantime
>>> my best bet may be to repackage the 3rd party jar minus its web-fragment.
>>>
>>> -R
>>>
>>> On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz <
>>> [hidden email]> wrote:
>>>
>>> Ryan,
>>>
>>> On 2/13/15 12:59 PM, Ryan Scharer wrote:
>>>>>> I'm not sure if this is a bug or not, but I can't find any relevant
>>>>>>  information in the spec to suggest the behavior is expected.
>>>>>>
>>>>>> There's a web-fragment in my classpath that I'd like to skip. The
>>>>>> only way to accomplish this that I know of is to put an
>>>>>> <absolute-ordering> stanza in my web.xml and omit an <others/>.
>>>>>> Though this has the desired effect of skipping the web-fragment I
>>>>>> don't want, it has the very negative side effect that my
>>>>>> ServletContainerInitializer doesn't get handed all instances of
>>>>>> WebApplicationInitializer anymore, despite its @HandlesTypes
>>>>>> annotation. If I add the <others/>, classpath scanning works fine,
>>>>>> but the undesired web-fragment comes back. I've tested this in the
>>>>>> latest 7.x and 8.x Tomcat releases.
>>>>>>
>>>>>> This begs two questions:
>>>>>>
>>>>>> 1. Why does specifying an <absolute-ordering> without an <others/>
>>>>>> kill classpath scanning, or at least the part of Tomcat
>>>>>> responsible for finding types specified by @HandlesTypes and giving
>>>>>> it to interested parties? 2. Is there an alternate way to skip a
>>>>>> web-fragment, short of ripping it out of the jar, which I really
>>>>>> don't want to do?
>>>
>>> It's unclear to me why <absolute-ordering> affects JAR scanning...
>>> absolute-ordering should affect only the processing of web-fragments.
>>> The Tomcat documentation for absolute-ordering makes it sounds like
>>> you have to mention a JAR name while the spec documentation makes it
>>> seem like you need to use the <name> element from web-fragments that
>>> are detected in JAR files.
>>>
>>> The whole thing is a can of worms, honestly.
>>>
>>> As for your inability to skip a web-fragment... that seems
>>> straightforward to me: if you have <others/> specified, then
>>> "everything else" will be processed in that order, including the
>>> web-fragment you don't want. There does not seem to be a way to
>>> blacklist a web-fragment short of completely removing it from your
>>> project's libraries.
>>>
>>> But the fact that the lack of <others> causes Tomcat to fail to do JAR
>>> scanning is surprising to me. I tend to prefer explicit configuration
>>> over all this scanning-related magic so I'm afraid I don't have any
>>> experience with this kind of thing. In fact, it's this kind of
>>> foolishness that makes me stick with explicitly-specified
>>> configurations instead of magic ones. Good luck figuring out how the
>>> magic works / is supposed to work!
>>>
>>> -chris
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]