>> As per the servlet spec > 5 first words are the issue.
Well, thats life ;) We only have to deal with tomcat, jetty and tomee. The rest will 95% work as well. And it’s always possible to do a deeper integration anyway. > We can force it „before" which should almost be enough. If you manually define the order or use the tomcat native integration to define the order or a certain Listener then this will overwrite all the user specified ordering, right? LieGrue, strub > Am 26.04.2015 um 09:19 schrieb Romain Manni-Bucau <[email protected]>: > > Le 26 avr. 2015 08:24, "Mark Struberg" <[email protected]> a écrit : >> >>> Break container usage >> >> As per the servlet spec only web-fragment.xml in jars of WEB-INF/lib must > get picked up automatically. >> > > 5 first words are the issue. > >> See servlet spec 8.2.1 „Modularity of web.xml“: >> >> „If a framework wants its META-INF/web-fragment.xml honored in such a way > that it augments a web application’s web.xml, the framework must be bundled > within the web application's WEB-INF/lib directory. >> … >> In other words, only JAR files bundled in a web application’s WEB-INF/lib > directory, but not those higher up in the class loading delegation chain, > need to be scanned for web-fragment.xml" >> >> So that one should not be a blocker. >> >>> I guess the only loss is some amount of >>> ordering control you might have had if you >>> included it in the parent web.xml directly. >> > > We can force it "before" which should almost be enough. > >> I had the exact other problem which brought me to this ;) >> In my lightweightee example I use deltaspike-jsf which has a web-fragment > for the window handler, ViewConfigPathValidator, etc. >> It has >> <ordering> >> <after> >> <others/> >> </after> >> </ordering> >> but _still_ gets executed before the WebBeansConfigurationListener of our > own local web.xml >> So I hoped that switching to web-fragment.xml for owb as well (with > before-others) should fix that. Still need to test. >> Need to check what’s going on. Or if this is a bug in the pretty old > tomcat7 I use… >> > > Side note: if done - no issue in tomee btw - should be a 1.6 and not 1.5.1 > IMO > >> LieGrue, >> strub >> >> >>> Am 26.04.2015 um 01:12 schrieb Joseph Bergmark <[email protected]>: >>> >>> It should be well supported on any servlet 3.0 compliant container as > its >>> part of the specification. I suppose it could be inconvenient for >>> application servers that already have OWB integration, but in that case > I >>> wouldn't expect the user to be including OWB in their application at > all. >>> >>> As long as we document that including the openwebbeans-web module into > your >>> application will cause a ServletContainerInitializer to automatically be >>> added, I don't see any harm in it. I guess the only loss is some > amount of >>> ordering control you might have had if you included it in the parent >>> web.xml directly. >>> >>> On Sat, Apr 25, 2015 at 5:14 PM, Romain Manni-Bucau < > [email protected]> >>> wrote: >>> >>>> Le 25 avr. 2015 21:58, "Mark Struberg" <[email protected]> a écrit : >>>>> >>>>> Hi! >>>>> >>>>> Should we add the WebBeansConfigurationListener (or later the two > split >>>> ones, see OWB-1055) into a web-fragment.xml inside our > openwebbeasns-web >>>> module? >>>>> >>>>> Pro: no need to add any listener manually + we should be neatly able > to >>>> define the default priorities (outermost listener). >>>>> Con: not sure yet, that’s what I’m curious about :) Any input? >>>>> >>>> >>>> Break container usage, not always well supported? >>>> >>>> That said could be done in another module. Would split lib and app >>>> artifacts which is good. >>>> >>>> Also the conversation filter needs to be handled prog so >>>> ServletContextInitializer sounds better. >>>> >>>>> >>>>> LieGrue, >>>>> strub
