Implement geofence standaone as a spring-boot application

[groldan]

Hi, I'm evaluating integrating Geofence as a microservice in geoserver-cloud

The approach used to integrate other GeoServer functionalities is not going to work or is gonna become a nightmare to maintain.

So I'd like to convert the app to spring-boot, for which I'd get funding. Hence this question asking if you guys would be interested in such work.

Note by converting to spring-boot, the application could be either a single-jar executable, or a .war as it is right now, or both, that's not a problem.

That would imply replacing CXF by Spring webmvc, already mentioned in #132.

Additionally, I'd like to make the REST API an "API first project", defining it in an OpenAPI 3 yaml file, and using code generation to create the server stub api and the java client.

This means the current "shared object model" would not be derived from the persistence object model, but from the API definition, with the additional benefit of separating those concerns, and the ability to create code-generated clients in other programming languages, may them be needed by anyone (for example, a JS client for MapStore, a python client for GeoNode, etc).

As of API backwards compatibility, I'm pretty sure we could respect the current XML object model, while adding JSON support too.

At the same time, it'd be possible to reuse the components directly for the GeoServer integrated version.

@etj @afabiani what do you guys think?

[etj]

Hi @groldan, yep it's a really cool idea.
A couple of points:

• CXF/webmvc: currently CXF provides both xml and json; I worked a bit on a PoC for this, but I saw the packet formats changed a lot, so we need to create lots of tests to make sure the json/xml formats stay the same.
• Most of the objects used in the REST operations are already defined as REST DTOs; anyway some DTOs still refer to classes of the internal model (such as LayerAttribute ) and yes, this shoud be improved.
• Last but not least: Where do we go with the standalone GUI? #156: what shall we do with the GUI? current implementation is obsolete and should be replaced with something more recent and maintenable. Probably the GUI part should be allowed to be installed as a different web service. I guess there is more to discuss about this point.

[groldan]

Hey, thanks for the prompt reply.

The GUI is definitely a very important aspect, yet I'm not sure I could secure funding for it, but will ask.

Would it do exactly the same as the gs integrated wicket module?

Unfortunately, the build fails right now with the following error so I can't check:

... Could not transfer artifact org.geotools:gt-wfs:pom:25-SNAPSHOT from/to boundless (https://repo.boundlessgeo.com/): 
Transfer failed for https://repo.boundlessgeo.com/org/geotools/gt-wfs/25-SNAPSHOT/gt-wfs-25-SNAPSHOT.pom: Unknown host repo.boundlessgeo.com -> [Help 1]

Looks easy to fix though.

That said, and back to your question, with the OpenAPI first approach, it should be "easy" to create a Single Page App in JS (NotMyAreaOfExperise (tm)) that talks to the API, so we have a single thing to maintain in regards to configuration.

The other, wild, probably stupid, approach would be to replicate a stripped down version of geoserver's wicket UI that contains only the geofence stuff... but sounds worse than it did in my head once written down...

[afabiani]

+1 @groldan thanks