Hi Konstantin,

I am referring to this code in ContextConfig.java:

// Step 9a. Make the merged web.xml available to other
        if (context.getLogEffectiveWebXml()) {
            log.info("web.xml:\n" + mergedWebXml);
        }

 // Step 10. Look for static resources packaged in JARs
                   Set<WebXml> resourceJars = new LinkedHashSet<>();
            if (orderedFragments != null) {
                for (WebXml fragment : orderedFragments) {
                    resourceJars.add(fragment);
                }
            }
            for (WebXml fragment : fragments.values()) {
                if (!resourceJars.contains(fragment)) {
                    resourceJars.add(fragment);
                }
            }
            processResourceJARs(resourceJars);


Apparently, it is only after logging mergeXml that the fragments are
considered; mergedWebXml thus has empty empty fragments at the time of
logging - and is not populated afterwards I believe (or - maybe - partially
populated without the full set of resourceJars) . It matches my experience.

Do you think I should file a bug and log the merged Xml after resourceJars
is indeed complete ?

Thanks,

loïc


On Sat, Sep 20, 2014 at 1:09 PM, Konstantin Kolinko <knst.koli...@gmail.com>
wrote:

> 2014-09-19 22:15 GMT+04:00 Loïc Tregan <l.tre...@gmail.com>:
> > Hi,
> >
> > Setting logEffectiveWebXml=true in context.xml does not log the web
> > fragments in the <absolute-ordering> clause of the output web.xml; it is
> > not specified.
> >
> > Is it expected ? Should I file a bug ?
> >
> > I think it is a convenient feature to debug in which order the web
> > fragments are loaded.
>
> It logs web.xml created from merging of all processed fragments and
> annotations.
>
> If data from your fragment are not included in the resulting web.xml,
> it means that you fragment is not effective (ignored, misconfigured
> etc.)
>
>
> If you need more specific help, you need to provide enough information
> for someone else to reproduce your issue.
>
> Check what version of specification your files are declaring.
> Cross-check your expectations with the Servlet specification text.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to