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
