Re: Running 5.7+ without TapestryFilter

Hi Thiago,

thanks for fixing it!

Works fine now with 5.8.1-SNAPSHOT without including the TapestryModule.

Cheers,
Ben

On Fri, Mar 18, 2022 at 4:07 AM Thiago H. de Paula Figueiredo <
[email protected]> wrote:

> 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 <
> [email protected]> wrote:
>
> > On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <[email protected]> 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
>