I've hit the Send button too soon. I've just committed a fix for the problem I described above and now I'm generating a new release with it.
Please let me know if it fixes this problem. On Thu, Mar 17, 2022 at 11:51 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <b...@netzgut.net> wrote: > >> Hi! >> > > Hello! > > >> But I ran into a "tapestry.version not defined" issue. >> The problem originates (as always) in our unique setup. >> We run our Tapestry applications (web and non-web) as "normal" Java >> application (e.g. "java -cp ... App") and programmatically create the >> Registry and TapestryAppInitializer, and a custom Filter for an embedded >> Jetty if web. >> >> In 5.6 the TapestryAppInitializer always added the TapestryModule >> (containing "tapestry.version"). >> Now, the TapestryFilter adds it instead via >> org.apache.tapestry5.TapestryFilter.provideExtraModuleClasses(ServletContext). >> We fixed the issue by ImportModule(TapestryModule.class) in our >> AppModule.But if a Tapestry app won't work without it, it should always add >> it IMO, > > regardless of using TapestryFilter. > > > I believe this is caused by an oversight on my part when I split > tapestry-http out of tapestry-core. I should have moved the factory > contribution of tapestry.version to TapestryHttpModule. > > >> >> >> That would make the new org.apache.tapestry5.TapestryFilter obsolete, >> though, because all it does is provide TapestryModule. >> I understand the general idea behind allowing filters to specify >> additional >> modules to be loaded. >> But it isn't used anywhere except for TapestryModule so far. >> >> If there's an agreement that this is a problem and that it should be >> reverted to the original behavior, I'll create an issue and fix it. >> But I didn't want to revert any recently introduced behavior without a >> discussion first. >> >> Cheers >> Ben >> > > > -- > Thiago > -- Thiago
