I see... It's really weird... We'll double check that. On Fri, Jun 21, 2019 at 7:00 PM Mark Thomas <ma...@apache.org> wrote:
> On 21/06/2019 13:48, Leonid Rozenblyum wrote: > > Thank you! > > I've looked and the behaviour in 8.0.30 appears to be the same. The > changes I was thinking of were a) much further back and b) unlikely to > impact distributable. > > Mark > > > > > > On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas <ma...@apache.org> wrote: > > > >> On 21/06/2019 12:39, Leonid Rozenblyum wrote: > >>> Hi Mark! > >>> Thanks for the explanation. > >>> > >>> So now it's mandatory for us to mark every web application > >> <distributable /> > >>> (and also ensure no dependencies in classpath are actual web fragments > >>> without distributable accidentally) > >>> > >>> About our upgrade: > >>> We've upgraded Tomcat > >>> Tomcat 8.0.30 -> Tomcat 9.0.16 > >>> (we are planning also the next update to Tomcat 9.0.21 to mitigate a > >> https > >>> issue but that's another story) > >>> > >>> In 8.0.30 just a <distributable /> in conf/web.xml has been enabled and > >>> that caused DeltaManager working (was able to check by catalina logs > and > >> by > >>> JMX manager and by the actual fact that session replication was > working). > >> > >> Interesting. I'll need to go back and check what was going on there. > >> There were some changes in that area as the Servlet EG clarified the > >> expected behaviour for "plugability" features. I didn't think anything > >> changed for distributable but it was a little while ago so I may have > >> forgotten. > >> > >> I'll report back what I find. > >> > >> Mark > >> > >> > >>> > >>> On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas <ma...@apache.org> wrote: > >>> > >>>> On 21/06/2019 09:54, Leonid Rozenblyum wrote: > >>>>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager > stopped > >>>>> initializing. > >>>>> StandardManager is used instead in cluster environment. > >>>> > >>>> Could you be more specific about version numbers please. > >>>> > >>>>> our global conf/web.xml contains <distributable /> as before. > >>>> > >>>> That is the default for conf/web.xml so it should not be necessary to > >>>> set it. > >>>> > >>>>> I found a possible workaround: to copy the <distributable /> tag to > the > >>>>> web.xml in the web applications itself. > >>>> > >>>> That is expected. Web applications need to be explicitly marked as > >>>> distributable. > >>>> > >>>>> However shouldn't it be inherited from the global conf/web.xml? > >>>> > >>>> No. For a web application to be distributable: > >>>> > >>>> - WEB-INF/web.xml needs to be marked as distributable > >>>> - any web-fragment.xml files present in the web app need to be marked > as > >>>> distributable > >>>> > >>>> Internally, Tomcat creates additional web-fragment.xml files for JAR > >>>> files that do not have one. These are marked as distributable by > default > >>>> to ensure they don't prevent the web app from being distributable. > >>>> > >>>> Internally, the global, host and tomcat specific web.xml files are > also > >>>> treated as fragments. They too are marked as distributable by default > >>>> for the same reason. > >>>> > >>>> Tomcat creates these fragments internally as it allows us to re-use > the > >>>> web.xml merge code. > >>>> > >>>>> Is it a known behavior change? > >>>> > >>>> The process has been essentially the same from the early 8.0.x > releases > >>>> since that is where web-fragment.xml files were introduced. > >>>> > >>>> Mark > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > >
