Forwarding to the list :-) ---------- Forwarded message ---------- From: Alessio Soldano <asoldano(a)redhat.com&gt; Date: Wed, Sep 27, 2017 at 10:24 PM Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically To: Christian Kaltepoth <christian(a)kaltepoth.de&gt; Hi Christian, On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth < christian(a)kaltepoth.de&gt; wrote: > > sorry for the delayed response. I agree that if some SPI would allow to > modify the builders, it should be done before the resource is registered in > the resource factory. Do you think such a SPI would be useful for others? > Probably yes, but your scenario might even be enough to justify it. I would be happy to contribute some code if it improves portability > between RESTEasy and the MVC RI. > Sure, feel free to work on that and send a PR. > Thanks for pointing me to the resteasy-cdi integration. I'll have a > deeper look at it in the next days. > OK, good, I hope that can offer some idea for integrating. Cheers Alessio _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

Hi Christian, first of all sorry for the late reply, long XMas break. Your proposal makes sense to me. For better backward compatibility, it might be worth having the new ResourceBuilder actually named (slightly) differently or in a subpackage, and let the static methods in the old ResourceBuilder delegate to a given (default) new builder. But we can also work on this as a second step. Thanks for your proposal, I'd be glad to review your PR. Cheers Alessio On Sun, Dec 24, 2017 at 9:45 AM, Christian Kaltepoth < christian(a)kaltepoth.de&gt; wrote: > Hi Alessio, > > sorry for the delayed response. I finally found some time to have a > deeper look at this. I would like to describe my idea, so I can get > feedback before starting the implementation. > > > To recap what I'm trying to achieve: Basically the idea is to create a > SPI which allows to alter the metadata of resource classes. I came up with > the following interface for such a SPI: > > public interface ResourceClassProcessor { > ResourceClass process( ResourceClass clazz ); > } > > IMO this interface provides most flexibility. The idea is similar to what > CDI provides with AnnotatedType > <https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedType...;. > Implementations of the new SPI can either return the provided class (if > they don't want to change it) or they can return a new instance, typically > something that wraps the original class and changes only a few methods. > > Integrating this SPI requires two refactorings of the existing code base, > but I really think that this will improve the overall structure of the > metadata handling: > > - Currently ResourceClass > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;, > ResourceMethod > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;, > etc. are classes with protected fields which are directly accessed by the > ResourceBuilder > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;. > The first required refactoring would be to extract interfaces from these > classes so that we get an interface ResourceClass with a default > implementation DefaultResourceClass. Same for ResourceMethod, etc. This > will allow other implementations of these interfaces later on. > - Currently ResourceBuilder > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... > has only static methods to build ResourceClasse instances. This makes it > difficult to "configure" this builder with such processors. Therefore, I > would like to refactor the builder from a "utility class" with static > methods to something that can be instantiated and therefore also be > configured. I think ResteasyProviderFactory > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... would > be a good place to create such a builder _once_ and then provide it to all > components that want to use it. > > With these refactorings integrating the new SPI should be easy. > ResteasyProviderFactory > <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... > could lookup the SPI implementations using the default provider mechanism. > The processors will then be feed into the ResourceBuilder when creating it. > The ResourceBuilder can then build the metadata for classes from > annotations (as it is done today) and after that apply all > ResourceClassProcessors before returning the ResourceClass to the other > components (like the registry). This will ensure that the processors are > applied consistently. > > I think the two refactorings mentioned above a worth the effort because > they improve the overall structure of the metadata package > <https://github.com/resteasy/Resteasy/tree/master/resteasy-jaxrs/src/main/... > and provides much more flexibility in the future. And they also allow > integrate the new SPI very easily. > > > What do you think? If you agree that the refactorings are a good thing, I > will start to work on them and provide a pull request. > > Christian > > > > 2017-09-27 22:25 GMT+02:00 Alessio Soldano <asoldano(a)redhat.com&gt;: > >> Forwarding to the list :-) >> >> >> ---------- Forwarded message ---------- >> From: Alessio Soldano <asoldano(a)redhat.com&gt; >> Date: Wed, Sep 27, 2017 at 10:24 PM >> Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically >> To: Christian Kaltepoth <christian(a)kaltepoth.de&gt; >> >> >> Hi Christian, >> >> On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth < >> christian(a)kaltepoth.de&gt; wrote: >> >>> >>> sorry for the delayed response. I agree that if some SPI would allow to >>> modify the builders, it should be done before the resource is registered in >>> the resource factory. Do you think such a SPI would be useful for others? >>> >> >> Probably yes, but your scenario might even be enough to justify it. >> >> >> I would be happy to contribute some code if it improves portability >>> between RESTEasy and the MVC RI. >>> >> >> Sure, feel free to work on that and send a PR. >> >> >>> Thanks for pointing me to the resteasy-cdi integration. I'll have a >>> deeper look at it in the next days. >>> >> >> OK, good, I hope that can offer some idea for integrating. >> >> Cheers >> Alessio >> >> >> >> _______________________________________________ >> resteasy-dev mailing list >> resteasy-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/resteasy-dev >> >> > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > >

OK, for the records, I've just merged https://github.com/resteasy/Resteasy/pull/1449 , which basically includes the changes Christian proposed. Now I think we need either a proof of concept of the integration this was needed for or a bit of test coverage for the spi. Christian, is this something you can provide too? Thanks On Thu, Jan 11, 2018 at 7:03 AM, Christian Kaltepoth < christian(a)kaltepoth.de&gt; wrote: > Hi Alessio, > > thanks a lot for the feedback. I'm not sure if spending time on keeping > the old ResourceBuilder API (the static methods) is worth the effort, > because it is used just in 2-3 places IIRC. But I'll have a look at this > while working on the PR. > > I'll try to split my work into a few PR so they are easier to review. > > Thanks a lot > > Christian > > 2018-01-10 15:18 GMT+01:00 Alessio Soldano <asoldano(a)redhat.com&gt;: > >> Hi Christian, >> first of all sorry for the late reply, long XMas break. >> Your proposal makes sense to me. For better backward compatibility, it >> might be worth having the new ResourceBuilder actually named (slightly) >> differently or in a subpackage, and let the static methods in the old >> ResourceBuilder delegate to a given (default) new builder. But we can also >> work on this as a second step. >> Thanks for your proposal, I'd be glad to review your PR. >> Cheers >> Alessio >> >> On Sun, Dec 24, 2017 at 9:45 AM, Christian Kaltepoth < >> christian(a)kaltepoth.de&gt; wrote: >> >>> Hi Alessio, >>> >>> sorry for the delayed response. I finally found some time to have a >>> deeper look at this. I would like to describe my idea, so I can get >>> feedback before starting the implementation. >>> >>> >>> To recap what I'm trying to achieve: Basically the idea is to create a >>> SPI which allows to alter the metadata of resource classes. I came up with >>> the following interface for such a SPI: >>> >>> public interface ResourceClassProcessor { >>> ResourceClass process( ResourceClass clazz ); >>> } >>> >>> IMO this interface provides most flexibility. The idea is similar to >>> what CDI provides with AnnotatedType >>> <https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedType...;. >>> Implementations of the new SPI can either return the provided class (if >>> they don't want to change it) or they can return a new instance, typically >>> something that wraps the original class and changes only a few methods. >>> >>> Integrating this SPI requires two refactorings of the existing code >>> base, but I really think that this will improve the overall structure of >>> the metadata handling: >>> >>> - Currently ResourceClass >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;, >>> ResourceMethod >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;, >>> etc. are classes with protected fields which are directly accessed by the >>> ResourceBuilder >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...;. >>> The first required refactoring would be to extract interfaces from these >>> classes so that we get an interface ResourceClass with a default >>> implementation DefaultResourceClass. Same for ResourceMethod, etc. This >>> will allow other implementations of these interfaces later on. >>> - Currently ResourceBuilder >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... >>> has only static methods to build ResourceClasse instances. This makes it >>> difficult to "configure" this builder with such processors. Therefore, I >>> would like to refactor the builder from a "utility class" with static >>> methods to something that can be instantiated and therefore also be >>> configured. I think ResteasyProviderFactory >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... would >>> be a good place to create such a builder _once_ and then provide it to all >>> components that want to use it. >>> >>> With these refactorings integrating the new SPI should be easy. >>> ResteasyProviderFactory >>> <https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... >>> could lookup the SPI implementations using the default provider mechanism. >>> The processors will then be feed into the ResourceBuilder when creating it. >>> The ResourceBuilder can then build the metadata for classes from >>> annotations (as it is done today) and after that apply all >>> ResourceClassProcessors before returning the ResourceClass to the other >>> components (like the registry). This will ensure that the processors are >>> applied consistently. >>> >>> I think the two refactorings mentioned above a worth the effort because >>> they improve the overall structure of the metadata package >>> <https://github.com/resteasy/Resteasy/tree/master/resteasy-jaxrs/src/main/... >>> and provides much more flexibility in the future. And they also allow >>> integrate the new SPI very easily. >>> >>> >>> What do you think? If you agree that the refactorings are a good thing, >>> I will start to work on them and provide a pull request. >>> >>> Christian >>> >>> >>> >>> 2017-09-27 22:25 GMT+02:00 Alessio Soldano <asoldano(a)redhat.com&gt;: >>> >>>> Forwarding to the list :-) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Alessio Soldano <asoldano(a)redhat.com&gt; >>>> Date: Wed, Sep 27, 2017 at 10:24 PM >>>> Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically >>>> To: Christian Kaltepoth <christian(a)kaltepoth.de&gt; >>>> >>>> >>>> Hi Christian, >>>> >>>> On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth < >>>> christian(a)kaltepoth.de&gt; wrote: >>>> >>>>> >>>>> sorry for the delayed response. I agree that if some SPI would allow >>>>> to modify the builders, it should be done before the resource is registered >>>>> in the resource factory. Do you think such a SPI would be useful for others? >>>>> >>>> >>>> Probably yes, but your scenario might even be enough to justify it. >>>> >>>> >>>> I would be happy to contribute some code if it improves portability >>>>> between RESTEasy and the MVC RI. >>>>> >>>> >>>> Sure, feel free to work on that and send a PR. >>>> >>>> >>>>> Thanks for pointing me to the resteasy-cdi integration. I'll have a >>>>> deeper look at it in the next days. >>>>> >>>> >>>> OK, good, I hope that can offer some idea for integrating. >>>> >>>> Cheers >>>> Alessio >>>> >>>> >>>> >>>> _______________________________________________ >>>> resteasy-dev mailing list >>>> resteasy-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/resteasy-dev >>>> >>>> >>> >>> >>> -- >>> Christian Kaltepoth >>> Blog: http://blog.kaltepoth.de/ >>> Twitter: http://twitter.com/chkal >>> GitHub: https://github.com/chkal >>> >>> >> > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > -- Alessio Soldano Associate Manager Red Hat <https://www.redhat.com> <https://red.ht/sig>

Hi Christian, On Fri, Mar 16, 2018 at 5:43 PM, Christian Kaltepoth < christian(a)kaltepoth.de&gt; wrote: > Hi Alessio, > > thanks a lot for your help merging the pull request. > > I already created a custom ResourceClassProcessor for the MVC 1.0 > reference implementation Ozark which automatically adds > @Produces("text/html") to all MVC controllers. > > See the corresponding code here: > > > https://github.com/chkal/ozark/tree/15920a07429b71a15fab8ae19e8e9cad50bba... > > Would this be a proof of concept as you mention it? > > Yes, cool. I'll probably add an integration test within RESTEasy doing something similar. Thanks > -- Alessio Soldano Associate Manager Red Hat <https://www.redhat.com> <https://red.ht/sig>

Hi Christian, I definitely want those changes in next version of WildFly (13), which I think is planned in less than 2 months from now. This said, as to how to make that happen, we might create a new branch (3.6) from 3.5 very soon; basically the idea would be to go for a new minor release to pull a bunch of new features (including yours), leaving bug fixes only on 3.5.x. As soon as the final decision is taken, I'll merge the changes to the relevant branch. Thanks On Thu, Apr 5, 2018 at 7:07 PM, Christian Kaltepoth < christian(a)kaltepoth.de&gt; wrote: > Hi Alessio, > > just a quick question. I'm currently working on the TCK for MVC 1.0 and I > was wondering if you are still planning to integrate the changes into the > 3.5 branch. It would be interesting to know, because this will be most > likely one of the few reasons why the MVC 1.0 RI won't pass the TCK on > Wildfly. > > Christian > > Am Do., 22. März 2018 um 17:46 Uhr schrieb Alessio Soldano < > asoldano(a)redhat.com&gt;: > >> Hi Christian, >> >> On Fri, Mar 16, 2018 at 5:43 PM, Christian Kaltepoth < >> christian(a)kaltepoth.de&gt; wrote: >> >>> Hi Alessio, >>> >>> thanks a lot for your help merging the pull request. >>> >>> I already created a custom ResourceClassProcessor for the MVC 1.0 >>> reference implementation Ozark which automatically adds >>> @Produces("text/html") to all MVC controllers. >>> >>> See the corresponding code here: >>> >>> >>> https://github.com/chkal/ozark/tree/15920a07429b71a15fab8ae19e8e9cad50bba... >>> >>> Would this be a proof of concept as you mention it? >>> >>> >> Yes, cool. I'll probably add an integration test within RESTEasy doing >> something similar. >> Thanks >> >>> >> >> >> -- >> >> Alessio Soldano >> >> Associate Manager >> >> Red Hat >> >> <https://www.redhat.com> >> <https://red.ht/sig> >> > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > -- Alessio Soldano Associate Manager Red Hat <https://www.redhat.com> <https://red.ht/sig>