Hey all,
The Style endpoint is basically 100% at this point. Thanks to Torben for
the help as well.
https://github.com/boundlessgeo/geoserver/tree/spring_mvc_example/src/rest-ng
I also have some brief notes written about it here:
https://github.com/geoserver/geoserver/wiki/REST-Refresh-Notes-and-Tips
Let me know if there's any questions or comments. One thing that's not
supported right now are the Style extension end points. I still need to
look at how those are handled. Many of the extensions lack their own tests
for this though.
Cheers,
Devon
On Thu, Mar 16, 2017 at 9:46 AM, Matt Kruszewski <
mkruszew...@boundlessgeo.com> wrote:
>
> Hi Devon,
>
> > Using FreeMarker views is probably the best option, but probably lead to
> very, very slightly more complicated Controllers.
>
> In my experience, that's right. Generally, @ResponseBody controller
> methods are meant for directly returning the object (in a REST-y kind of
> way), while the traditional ModelAndView-type (non-@ResponseBody) methods
> are meant for rendering the object with a view / template like Freemarker.
>
> You *could* mix the concepts, e.g., by using a @ResponseBody controller
> method to return an object for "Accept: text/html", and then using an
> HttpMessageConverter to try to render it as HTML using a template. But I
> think that would be inviting complexity in the wrong place -- Spring treats
> the components as "orthogonal," like you said. The controllers would not
> even be able to select an intended view, so the http message converter
> would have to figure it out.
>
> Keeping them separate costs one additional method, but to me at least, it
> would be a more natural and clear use of the framework, and shouldn't be
> any more complicated if the underlying logic is shared. It should also
> cause fewer surprises down the line.
>
> See an example here: https://spring.io/blog/2013/05/11/content-
> negotiation-using-spring-mvc (under "Combining Data and Presentation
> Formats").
>
> One other note, while on the topic of serialization. We've been talking
> about docs autogeneration tools that are based on introspection of the
> framework annotations, like Swagger/Springfox -- but such tools will
> generally not be aware of arbitrary serialization logic that happens
> outside of the controller. I think some more research is required to figure
> out how big the gap is between the actual results of an API call and what
> those tools will be able to introspect.
>
> - Matt
>
> On Wed, Mar 15, 2017 at 2:58 PM, Devon Tucker <dtuc...@boundlessgeo.com>
> wrote:
>
>> > I think the geofence-server used spring mvc - could that be providing
>> your conflict?
>>
>> Probably not. I don't have any community modules enabled.
>>
>> > Is there any documentation explains to look at for these two options?
>>
>> I'll try to compile the results of my research. Using FreeMarker views is
>> probably the best option, but probably lead to very, very slightly more
>> complicated Controllers.
>>
>> > Yes, we outlined that as part of the plan (it was one of the reasons
>> we thought this was possible).
>>
>> It is possible. It's just not entirely clear on the details yet. XML and
>> JSON serialization all have small bits of customization depending on what's
>> being returned (see ReflectiveJSON/XMLFormat.java). Currently these
>> customizations are part of the type hierarchy of the RESTlet resource being
>> accessed which is where the wrinkle comes from. Response serialization in
>> Spring MVC is fairly detached from the controller itself and more
>> centralized. It's something that just needs more research, in particular
>> documenting the various bits of customization that already exist.
>>
>> On Wed, Mar 15, 2017 at 10:57 AM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Thanks Devon:
>>>
>>> That's about it. Just this raised a decent few questions and problems
>>>> for me:
>>>>
>>>> - Right off the bat despite mapping my new endpoint to "/restng/styles"
>>>> I found that it actually ended up being mapped to "/rest/restng/styles". I
>>>> can't for the life of me figure out why that's happening. I tried removing
>>>> the existing rest and restconfig modules from the project, removed the REST
>>>> wrapper config and still had this issue. Maybe not a big issue in practice,
>>>> since we want all the end points to be under /rest presumably, but it'd
>>>> certainly be nice to know WHY this happens. Something to do with the
>>>> AdvancedDispatchFilter maybe? (In fact after a little digging this seems to
>>>> be the "culprit")
>>>>
>>>> - Conflicting Spring MVC contexts. I used the <mvc:annotation-driven/>
>>>> directive to enable Spring MVC in my module. Then I added a new
>>>> HttpMessageConverter (like this https://dzone.com/articles/customizing)
>>>> to customize response handling. I could see the new converter being
>>>> instantiated and added to the list of converters, however during the
>>>> response cycle it was nowhere to be found. It seemed like internally there
>>>> was another Spring context that was being used that had the default
>>>> converters. If I remove the <mvc:annotation-driven> directive from my
>>>> context then my new converter DOES get used though. This is interesting
>>>> though because the only references to Spring MVC are in community.
>>>>
>>>
>>> I think the geofence-server used spring mvc - could that be providing
>>> your conflict?
>>> - https://github.com/geoserver/geoserver/blob/master/src/com
>>> munity/geofence-server/src/main/java/org/geoserver/geofence/
>>> rest/RolesRestController.java
>>>
>>> - How should HTML responses be handled? Spring MVC RestControllers
>>>> aren't really meant to return HTML. AFAICT the options are use the actual
>>>> ModelAndView functionality with freemarker views, which would involve
>>>> separate controller methods for HTML calls, or to create a new
>>>> HttpMessageConverter to handle HTML requests. Both probably have issues.
>>>> Creating a new MessageConverter is a little problematic, since these are
>>>> centralized and orthogonal to the actual controllers. HTML responses in the
>>>> current REST framework rely a lot on the type hierarchy of the RESTlet
>>>> controller that handles the request. It's a little tougher to do it this
>>>> way in Spring MVC because the response encoding happens outside the
>>>> controller lifecycle.
>>>>
>>>
>>> Is there any documentation explains to look at for these two options?
>>>
>>> My quick search found more examples of using freemarker views (and I
>>> think we use freemarker elsewhere).
>>>
>>> - This seems a little more straightforward, but I assume we want to
>>>> re-use all the existing XML/JSON serialization. This will require custom
>>>> MessageConverters for those.
>>>>
>>>
>>> Yes, we outlined that as part of the plan (it was one of the reasons we
>>> thought this was possible).
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
