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