Re: [ANNOUNCEMENT] Tapestry 5.4.4

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <ma...@nesluop.dk>
wrote:

> Hi
>
> Hello!


> We are using some pretty complex data models with deep interface
> hierarchies and generics, and I ended up replacing the internals of
> GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) to
> get correct behavior


Would it be possible to share your GenericUtils implementation using Guava
with the Tapestry project? Also, what's the ticket you posted before? We
definitely want to fix it for the 5.5.0 release. I already got another
report of a similar problem from another person and it would be nice to
reuse your solution if possible.


> (often tapestry would complain that some "setter" was
> not found or similar because it resolved the type to something higher in
> the interface/object hierarchy and missed the correct method override due
> to typing or something else. (I spent some time on attempting to fix the
> tapestry implementation, but ended up thinking it was a waste of time
> trying to replicate functionality that was already coded (more correctly)
> by other people, and picked guava as that was already present in our
> dependencies).
>
> Perhaps it is possible to find a lightweight,/focused library with a
> compatible license today, that tapestry could rely on, instead of
> attempting to implement this on its own.
>
> This is obviously not a widespread problem, but it is one of correctness
> and it tickles my OCD ;)
>
> --
> Chris
>
> On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski <
> > rafael@juicycocktail.com>
> > wrote:
> >
> > > Congratulations! Thanks to the core team for your continuous work and
> the
> > > effort you put into maintaining Tapestry.
> > >
> >
> > Thanks!
> >
> >
> > > I think the whole industry goes the way of trying to simplify things
> > (just
> > > take a look at the most recent programming languages & frameworks). If
> > > we’re talking about modernizing and competing with other frameworks, I
> > > would like to see Tapestry reducing the complexity that is currently
> > > required to grasp the framework and its various concepts (which are
> > > technically great, but sometimes hard to understand if you just start
> > > working with Tapestry). I think this will only work by providing old &
> > new
> > > APIs at the same time and by making the upgrade path and improvements
> > very
> > > clear in the documentation.
> > >
> >
> > Well, some stuff is indeed not simple, and I'd say the form support is
> the
> > part which could use some new components to make at least the simpler
> > scenarios simpler to implement (for example, when there are no loops).
> > Which other areas do you think could or should be simplified?
> >
> >
> > > Personally I’m also getting into the vibe of smaller services that
> > > communicate with each other, instead of this one monolithic giant that
> > > tries to be everything, but is nothing in the end. We use
> > bootique-tapestry
> > > (and also other Bootique-compatible integrations). I would like to see
> > > Tapestry to also go in this direction and improve integration on
> similar
> > > deployment environments.
> > >
> >
> > We could definitely have some ideas to make microservices easier to build
> > on the top of Tapestry-IoC.
> >
> >
> > > On the other side, I’m currently pretty happy with the state of
> Tapestry
> > > and with the framework keeping up with modern Java versions.
> > >
> >
> > Thanks!
> >
> > --
> > Thiago
> >
>


-- 
Thiago

Re: [ANNOUNCEMENT] Tapestry 5.4.4

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen <ma...@nesluop.dk> wrote:

> Hi
>

Hello!


> The "fix" for GenericsUtils is attached. I think that Guava is not the
> proper general solution as it is a rather huge beast to bring in, just to
> get access to its TypeToken. Personally I would prefer a lighter solution.
>

Thank you very much!

Could you please create an issue and post the fixed GenericUtils there?
This way, it's clear the code was contributed and the copyright situation
is clear and correct.


> We have been running this code in production since medio '16 without
> requiring any more fixes. I can see from my commit comment back then, that
> I initially attempted to fix GenericsUtils itself, then attempted to use
> the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as
> it was already a dependency of our application. If the reflect stuff from
> commons-lang3 could be made to work, that would not require any additional
> dependencies being added and be a good solution IMO.
>

I was thinking of creating a separate subproject/JAR, for backward
compatibility reasons, so anyone wanting to use the Guava-based one could
just easily add the dependency, at least until we find a smaller solution
in the future.


> Revisiting our override code I also see that we have a custom
> PropertyAccessImpl in place, that one fixes some cases where the Java
> Introspector fails to locate some setters, but I see that the Tapestry
> class has received some changes after our version was created, so I
> probably need to check whether that one is still necessary.
>

PropertyAccessImpl does indeed cover some cases the Java introspector
doesn't and it did evolve in the latest years, so I agree this may not be
necessary anymore.

Thanks again!


> --
> Chris
>
>
> On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <ma...@nesluop.dk>
>> wrote:
>>
>> > Hi
>> >
>> > Hello!
>>
>>
>> > We are using some pretty complex data models with deep interface
>> > hierarchies and generics, and I ended up replacing the internals of
>> > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava)
>> to
>> > get correct behavior
>>
>>
>> Would it be possible to share your GenericUtils implementation using Guava
>> with the Tapestry project? Also, what's the ticket you posted before? We
>> definitely want to fix it for the 5.5.0 release. I already got another
>> report of a similar problem from another person and it would be nice to
>> reuse your solution if possible.
>>
>>
>> > (often tapestry would complain that some "setter" was
>> > not found or similar because it resolved the type to something higher in
>> > the interface/object hierarchy and missed the correct method override
>> due
>> > to typing or something else. (I spent some time on attempting to fix the
>> > tapestry implementation, but ended up thinking it was a waste of time
>> > trying to replicate functionality that was already coded (more
>> correctly)
>> > by other people, and picked guava as that was already present in our
>> > dependencies).
>> >
>> > Perhaps it is possible to find a lightweight,/focused library with a
>> > compatible license today, that tapestry could rely on, instead of
>> > attempting to implement this on its own.
>> >
>> > This is obviously not a widespread problem, but it is one of correctness
>> > and it tickles my OCD ;)
>> >
>> > --
>> > Chris
>> >
>> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo <
>> > thiagohp@gmail.com> wrote:
>> >
>> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski <
>> > > rafael@juicycocktail.com>
>> > > wrote:
>> > >
>> > > > Congratulations! Thanks to the core team for your continuous work
>> and
>> > the
>> > > > effort you put into maintaining Tapestry.
>> > > >
>> > >
>> > > Thanks!
>> > >
>> > >
>> > > > I think the whole industry goes the way of trying to simplify things
>> > > (just
>> > > > take a look at the most recent programming languages & frameworks).
>> If
>> > > > we’re talking about modernizing and competing with other
>> frameworks, I
>> > > > would like to see Tapestry reducing the complexity that is currently
>> > > > required to grasp the framework and its various concepts (which are
>> > > > technically great, but sometimes hard to understand if you just
>> start
>> > > > working with Tapestry). I think this will only work by providing
>> old &
>> > > new
>> > > > APIs at the same time and by making the upgrade path and
>> improvements
>> > > very
>> > > > clear in the documentation.
>> > > >
>> > >
>> > > Well, some stuff is indeed not simple, and I'd say the form support is
>> > the
>> > > part which could use some new components to make at least the simpler
>> > > scenarios simpler to implement (for example, when there are no loops).
>> > > Which other areas do you think could or should be simplified?
>> > >
>> > >
>> > > > Personally I’m also getting into the vibe of smaller services that
>> > > > communicate with each other, instead of this one monolithic giant
>> that
>> > > > tries to be everything, but is nothing in the end. We use
>> > > bootique-tapestry
>> > > > (and also other Bootique-compatible integrations). I would like to
>> see
>> > > > Tapestry to also go in this direction and improve integration on
>> > similar
>> > > > deployment environments.
>> > > >
>> > >
>> > > We could definitely have some ideas to make microservices easier to
>> build
>> > > on the top of Tapestry-IoC.
>> > >
>> > >
>> > > > On the other side, I’m currently pretty happy with the state of
>> > Tapestry
>> > > > and with the framework keeping up with modern Java versions.
>> > > >
>> > >
>> > > Thanks!
>> > >
>> > > --
>> > > Thiago
>> > >
>> >
>>
>>
>> --
>> Thiago
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org



-- 
Thiago

Re: [ANNOUNCEMENT] Tapestry 5.4.4

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

By the way, I've just found this ticket, so you don't need to create
another: https://issues.apache.org/jira/browse/TAP5-2560

On Tue, Jan 8, 2019 at 7:38 PM Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:

> On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen <ma...@nesluop.dk>
> wrote:
>
>> Hi
>>
>
> Hello!
>
>
>> The "fix" for GenericsUtils is attached.
>>
>
> I don't think the attachment worked. Could you please post it inline? Or,
> better yet, to a Jira issue? Thanks in advance. :)
>
>
>> I think that Guava is not the proper general solution as it is a rather
>> huge beast to bring in, just to get access to its TypeToken. Personally I
>> would prefer a lighter solution.
>>
>> We have been running this code in production since medio '16 without
>> requiring any more fixes. I can see from my commit comment back then, that
>> I initially attempted to fix GenericsUtils itself, then attempted to use
>> the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as
>> it was already a dependency of our application. If the reflect stuff from
>> commons-lang3 could be made to work, that would not require any additional
>> dependencies being added and be a good solution IMO.
>>
>> I'm not sure I did create a ticket for the GenericsUtils issue, I may
>> just have asked on the list to see if anyone else was had experienced
>> something similar.
>>
>> Revisiting our override code I also see that we have a custom
>> PropertyAccessImpl in place, that one fixes some cases where the Java
>> Introspector fails to locate some setters, but I see that the Tapestry
>> class has received some changes after our version was created, so I
>> probably need to check whether that one is still necessary.
>>
>> --
>> Chris
>>
>>
>> On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo <
>> thiagohp@gmail.com> wrote:
>>
>>> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <ma...@nesluop.dk>
>>> wrote:
>>>
>>> > Hi
>>> >
>>> > Hello!
>>>
>>>
>>> > We are using some pretty complex data models with deep interface
>>> > hierarchies and generics, and I ended up replacing the internals of
>>> > GenericsUtils with calls to com.google.common.reflect.TypeToken
>>> (Guava) to
>>> > get correct behavior
>>>
>>>
>>> Would it be possible to share your GenericUtils implementation using
>>> Guava
>>> with the Tapestry project? Also, what's the ticket you posted before? We
>>> definitely want to fix it for the 5.5.0 release. I already got another
>>> report of a similar problem from another person and it would be nice to
>>> reuse your solution if possible.
>>>
>>>
>>> > (often tapestry would complain that some "setter" was
>>> > not found or similar because it resolved the type to something higher
>>> in
>>> > the interface/object hierarchy and missed the correct method override
>>> due
>>> > to typing or something else. (I spent some time on attempting to fix
>>> the
>>> > tapestry implementation, but ended up thinking it was a waste of time
>>> > trying to replicate functionality that was already coded (more
>>> correctly)
>>> > by other people, and picked guava as that was already present in our
>>> > dependencies).
>>> >
>>> > Perhaps it is possible to find a lightweight,/focused library with a
>>> > compatible license today, that tapestry could rely on, instead of
>>> > attempting to implement this on its own.
>>> >
>>> > This is obviously not a widespread problem, but it is one of
>>> correctness
>>> > and it tickles my OCD ;)
>>> >
>>> > --
>>> > Chris
>>> >
>>> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo <
>>> > thiagohp@gmail.com> wrote:
>>> >
>>> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski <
>>> > > rafael@juicycocktail.com>
>>> > > wrote:
>>> > >
>>> > > > Congratulations! Thanks to the core team for your continuous work
>>> and
>>> > the
>>> > > > effort you put into maintaining Tapestry.
>>> > > >
>>> > >
>>> > > Thanks!
>>> > >
>>> > >
>>> > > > I think the whole industry goes the way of trying to simplify
>>> things
>>> > > (just
>>> > > > take a look at the most recent programming languages &
>>> frameworks). If
>>> > > > we’re talking about modernizing and competing with other
>>> frameworks, I
>>> > > > would like to see Tapestry reducing the complexity that is
>>> currently
>>> > > > required to grasp the framework and its various concepts (which are
>>> > > > technically great, but sometimes hard to understand if you just
>>> start
>>> > > > working with Tapestry). I think this will only work by providing
>>> old &
>>> > > new
>>> > > > APIs at the same time and by making the upgrade path and
>>> improvements
>>> > > very
>>> > > > clear in the documentation.
>>> > > >
>>> > >
>>> > > Well, some stuff is indeed not simple, and I'd say the form support
>>> is
>>> > the
>>> > > part which could use some new components to make at least the simpler
>>> > > scenarios simpler to implement (for example, when there are no
>>> loops).
>>> > > Which other areas do you think could or should be simplified?
>>> > >
>>> > >
>>> > > > Personally I’m also getting into the vibe of smaller services that
>>> > > > communicate with each other, instead of this one monolithic giant
>>> that
>>> > > > tries to be everything, but is nothing in the end. We use
>>> > > bootique-tapestry
>>> > > > (and also other Bootique-compatible integrations). I would like to
>>> see
>>> > > > Tapestry to also go in this direction and improve integration on
>>> > similar
>>> > > > deployment environments.
>>> > > >
>>> > >
>>> > > We could definitely have some ideas to make microservices easier to
>>> build
>>> > > on the top of Tapestry-IoC.
>>> > >
>>> > >
>>> > > > On the other side, I’m currently pretty happy with the state of
>>> > Tapestry
>>> > > > and with the framework keeping up with modern Java versions.
>>> > > >
>>> > >
>>> > > Thanks!
>>> > >
>>> > > --
>>> > > Thiago
>>> > >
>>> >
>>>
>>>
>>> --
>>> Thiago
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> --
> Thiago
>


-- 
Thiago

Re: [ANNOUNCEMENT] Tapestry 5.4.4

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen <ma...@nesluop.dk> wrote:

> Hi
>

Hello!


> The "fix" for GenericsUtils is attached.
>

I don't think the attachment worked. Could you please post it inline? Or,
better yet, to a Jira issue? Thanks in advance. :)


> I think that Guava is not the proper general solution as it is a rather
> huge beast to bring in, just to get access to its TypeToken. Personally I
> would prefer a lighter solution.
>
> We have been running this code in production since medio '16 without
> requiring any more fixes. I can see from my commit comment back then, that
> I initially attempted to fix GenericsUtils itself, then attempted to use
> the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as
> it was already a dependency of our application. If the reflect stuff from
> commons-lang3 could be made to work, that would not require any additional
> dependencies being added and be a good solution IMO.
>
> I'm not sure I did create a ticket for the GenericsUtils issue, I may just
> have asked on the list to see if anyone else was had experienced something
> similar.
>
> Revisiting our override code I also see that we have a custom
> PropertyAccessImpl in place, that one fixes some cases where the Java
> Introspector fails to locate some setters, but I see that the Tapestry
> class has received some changes after our version was created, so I
> probably need to check whether that one is still necessary.
>
> --
> Chris
>
>
> On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <ma...@nesluop.dk>
>> wrote:
>>
>> > Hi
>> >
>> > Hello!
>>
>>
>> > We are using some pretty complex data models with deep interface
>> > hierarchies and generics, and I ended up replacing the internals of
>> > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava)
>> to
>> > get correct behavior
>>
>>
>> Would it be possible to share your GenericUtils implementation using Guava
>> with the Tapestry project? Also, what's the ticket you posted before? We
>> definitely want to fix it for the 5.5.0 release. I already got another
>> report of a similar problem from another person and it would be nice to
>> reuse your solution if possible.
>>
>>
>> > (often tapestry would complain that some "setter" was
>> > not found or similar because it resolved the type to something higher in
>> > the interface/object hierarchy and missed the correct method override
>> due
>> > to typing or something else. (I spent some time on attempting to fix the
>> > tapestry implementation, but ended up thinking it was a waste of time
>> > trying to replicate functionality that was already coded (more
>> correctly)
>> > by other people, and picked guava as that was already present in our
>> > dependencies).
>> >
>> > Perhaps it is possible to find a lightweight,/focused library with a
>> > compatible license today, that tapestry could rely on, instead of
>> > attempting to implement this on its own.
>> >
>> > This is obviously not a widespread problem, but it is one of correctness
>> > and it tickles my OCD ;)
>> >
>> > --
>> > Chris
>> >
>> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo <
>> > thiagohp@gmail.com> wrote:
>> >
>> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski <
>> > > rafael@juicycocktail.com>
>> > > wrote:
>> > >
>> > > > Congratulations! Thanks to the core team for your continuous work
>> and
>> > the
>> > > > effort you put into maintaining Tapestry.
>> > > >
>> > >
>> > > Thanks!
>> > >
>> > >
>> > > > I think the whole industry goes the way of trying to simplify things
>> > > (just
>> > > > take a look at the most recent programming languages & frameworks).
>> If
>> > > > we’re talking about modernizing and competing with other
>> frameworks, I
>> > > > would like to see Tapestry reducing the complexity that is currently
>> > > > required to grasp the framework and its various concepts (which are
>> > > > technically great, but sometimes hard to understand if you just
>> start
>> > > > working with Tapestry). I think this will only work by providing
>> old &
>> > > new
>> > > > APIs at the same time and by making the upgrade path and
>> improvements
>> > > very
>> > > > clear in the documentation.
>> > > >
>> > >
>> > > Well, some stuff is indeed not simple, and I'd say the form support is
>> > the
>> > > part which could use some new components to make at least the simpler
>> > > scenarios simpler to implement (for example, when there are no loops).
>> > > Which other areas do you think could or should be simplified?
>> > >
>> > >
>> > > > Personally I’m also getting into the vibe of smaller services that
>> > > > communicate with each other, instead of this one monolithic giant
>> that
>> > > > tries to be everything, but is nothing in the end. We use
>> > > bootique-tapestry
>> > > > (and also other Bootique-compatible integrations). I would like to
>> see
>> > > > Tapestry to also go in this direction and improve integration on
>> > similar
>> > > > deployment environments.
>> > > >
>> > >
>> > > We could definitely have some ideas to make microservices easier to
>> build
>> > > on the top of Tapestry-IoC.
>> > >
>> > >
>> > > > On the other side, I’m currently pretty happy with the state of
>> > Tapestry
>> > > > and with the framework keeping up with modern Java versions.
>> > > >
>> > >
>> > > Thanks!
>> > >
>> > > --
>> > > Thiago
>> > >
>> >
>>
>>
>> --
>> Thiago
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org



-- 
Thiago

Re: [ANNOUNCEMENT] Tapestry 5.4.4

[Chris Poulsen <ma...@nesluop.dk>]

Hi

The "fix" for GenericsUtils is attached. I think that Guava is not the
proper general solution as it is a rather huge beast to bring in, just to
get access to its TypeToken. Personally I would prefer a lighter solution.

We have been running this code in production since medio '16 without
requiring any more fixes. I can see from my commit comment back then, that
I initially attempted to fix GenericsUtils itself, then attempted to use
the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as
it was already a dependency of our application. If the reflect stuff from
commons-lang3 could be made to work, that would not require any additional
dependencies being added and be a good solution IMO.

I'm not sure I did create a ticket for the GenericsUtils issue, I may just
have asked on the list to see if anyone else was had experienced something
similar.

Revisiting our override code I also see that we have a custom
PropertyAccessImpl in place, that one fixes some cases where the Java
Introspector fails to locate some setters, but I see that the Tapestry
class has received some changes after our version was created, so I
probably need to check whether that one is still necessary.

-- 
Chris


On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:

> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <ma...@nesluop.dk>
> wrote:
>
> > Hi
> >
> > Hello!
>
>
> > We are using some pretty complex data models with deep interface
> > hierarchies and generics, and I ended up replacing the internals of
> > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava)
> to
> > get correct behavior
>
>
> Would it be possible to share your GenericUtils implementation using Guava
> with the Tapestry project? Also, what's the ticket you posted before? We
> definitely want to fix it for the 5.5.0 release. I already got another
> report of a similar problem from another person and it would be nice to
> reuse your solution if possible.
>
>
> > (often tapestry would complain that some "setter" was
> > not found or similar because it resolved the type to something higher in
> > the interface/object hierarchy and missed the correct method override due
> > to typing or something else. (I spent some time on attempting to fix the
> > tapestry implementation, but ended up thinking it was a waste of time
> > trying to replicate functionality that was already coded (more correctly)
> > by other people, and picked guava as that was already present in our
> > dependencies).
> >
> > Perhaps it is possible to find a lightweight,/focused library with a
> > compatible license today, that tapestry could rely on, instead of
> > attempting to implement this on its own.
> >
> > This is obviously not a widespread problem, but it is one of correctness
> > and it tickles my OCD ;)
> >
> > --
> > Chris
> >
> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo <
> > thiagohp@gmail.com> wrote:
> >
> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski <
> > > rafael@juicycocktail.com>
> > > wrote:
> > >
> > > > Congratulations! Thanks to the core team for your continuous work and
> > the
> > > > effort you put into maintaining Tapestry.
> > > >
> > >
> > > Thanks!
> > >
> > >
> > > > I think the whole industry goes the way of trying to simplify things
> > > (just
> > > > take a look at the most recent programming languages & frameworks).
> If
> > > > we’re talking about modernizing and competing with other frameworks,
> I
> > > > would like to see Tapestry reducing the complexity that is currently
> > > > required to grasp the framework and its various concepts (which are
> > > > technically great, but sometimes hard to understand if you just start
> > > > working with Tapestry). I think this will only work by providing old
> &
> > > new
> > > > APIs at the same time and by making the upgrade path and improvements
> > > very
> > > > clear in the documentation.
> > > >
> > >
> > > Well, some stuff is indeed not simple, and I'd say the form support is
> > the
> > > part which could use some new components to make at least the simpler
> > > scenarios simpler to implement (for example, when there are no loops).
> > > Which other areas do you think could or should be simplified?
> > >
> > >
> > > > Personally I’m also getting into the vibe of smaller services that
> > > > communicate with each other, instead of this one monolithic giant
> that
> > > > tries to be everything, but is nothing in the end. We use
> > > bootique-tapestry
> > > > (and also other Bootique-compatible integrations). I would like to
> see
> > > > Tapestry to also go in this direction and improve integration on
> > similar
> > > > deployment environments.
> > > >
> > >
> > > We could definitely have some ideas to make microservices easier to
> build
> > > on the top of Tapestry-IoC.
> > >
> > >
> > > > On the other side, I’m currently pretty happy with the state of
> > Tapestry
> > > > and with the framework keeping up with modern Java versions.
> > > >
> > >
> > > Thanks!
> > >
> > > --
> > > Thiago
> > >
> >
>
>
> --
> Thiago
>