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 < thiag...@gmail.com> wrote: > On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen <mailingl...@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 < >> thiag...@gmail.com> wrote: >> >>> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <mailingl...@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 < >>> > thiag...@gmail.com> wrote: >>> > >>> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < >>> > > raf...@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-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org > > > > -- > Thiago > -- Thiago
