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 <
ch...@christopherschultz.net> 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to