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