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 < 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
