You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Thiago H. de Paula Figueiredo" <th...@gmail.com> on 2022/03/18 02:51:12 UTC
Re: Running 5.7+ without TapestryFilter
On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <be...@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
Re: Running 5.7+ without TapestryFilter
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sat, Mar 19, 2022 at 2:19 PM Ben Weidig <be...@netzgut.net> wrote:
> Hi Thiago,
>
Hello, Ben!
> thanks for fixing it!
>
My pleasure!
> Works fine now with 5.8.1-SNAPSHOT without including the TapestryModule.
>
Thanks for testing! And apologies for not getting this right when
tapestry-http was split.
Cheers!
>
> Cheers,
> Ben
>
> On Fri, Mar 18, 2022 at 4:07 AM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> 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 <
> > thiagohp@gmail.com> wrote:
> >
> > > On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <be...@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
> >
>
--
Thiago
Re: Running 5.7+ without TapestryFilter
Posted by Ben Weidig <be...@netzgut.net>.
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 <
thiagohp@gmail.com> 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 <
> thiagohp@gmail.com> wrote:
>
> > On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <be...@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
>
Re: Running 5.7+ without TapestryFilter
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
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 <
thiagohp@gmail.com> wrote:
> On Tue, Dec 28, 2021 at 12:17 PM Ben Weidig <be...@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