[Geoserver-devel] user/role spring rest api

[Niels_Charlier]

Hello,

While doing a pull request on the geofence-server rest api, I had a question. This rest api is made in the spring rest api, unlike the rest of geoserver which uses restful. Jody suggested we might wish to (gradually) move towards that system, and I prefer it as well, It is very easy to read and write.

Additionally to that, I have also made a rest api for user/groups and roles in the same fashion. The spring classes only rely on one additional dependency above the normal spring stuff, and that is spring-oxm (handles the xml to object conversions).

Now the user and role stuff doesn't really belong in the geofence-server module, because people might want to use it if they are using the default security subsystem and not geofence. So currently these are the options:

(0) Leave the user/role spring rest api only for geofence-server users;
(1) My first proposal was to create a new community module rest-sec with all the common security rest api.
However, in the meantime Christian is making a rest api for security rules in the standard subsystem, and is doing this the traditional way with restful and adding it to the existing restconfig module, so that seems kind of off the table;
(2) My other proposal was to create a new module restconfig-ng that will hold all future spring rest api stuff, keeping the two systems separate as (if) we gradually move from one to the other.
(3) Simply add the user/role rest api classes, including the oxm dependency, to the existing restconfig module as well. That would make that module a mixture of the two systems.

Regards
Niels

[Andrea_Aime4]

On Wed, May 20, 2015 at 10:38 AM, Niels Charlier <niels@anonymised.com> wrote:

Hello,

While doing a pull request on the geofence-server rest api, I had a
question. This rest api is made in the spring rest api, unlike the rest
of geoserver which uses restful. Jody suggested we might wish to
(gradually) move towards that system, and I prefer it as well, It is
very easy to read and write.

Not against it, but since it will create a ton of "tech debt", we need a
proposal
and all devs to agree that from now all new restlets are going to be written
with Spring.
Also, how do you intend to keep the rest-config module working with
a mix of the two systems, can actually gradually migrate, or would
we have to rewrite all restconfig in a single shot?

Additionally to that, I have also made a rest api for user/groups and
roles in the same fashion. The spring classes only rely on one
additional dependency above the normal spring stuff, and that is
spring-oxm (handles the xml to object conversions).

GeoServer heavily relies on XStream for that task, is this
another technology you're proposing as a replacement for the future?
I see that spring-oxm can use XStream, but does not look like it's the
recommended way, can you clarify?

Now the user and role stuff doesn't really belong in the geofence-server
module, because people might want to use it if they are using the
default security subsystem and not geofence. So currently these are the
options:

(0) Leave the user/role spring rest api only for geofence-server users;
(1) My first proposal was to create a new community module rest-sec with
all the common security rest api.
However, in the meantime Christian is making a rest api for security
rules in the standard subsystem, and is doing this the traditional way
with restful and adding it to the existing restconfig module, so that
seems kind of off the table;
(2) My other proposal was to create a new module restconfig-ng that will
hold all future spring rest api stuff, keeping the two systems separate
as (if) we gradually move from one to the other.
(3) Simply add the user/role rest api classes, including the oxm
dependency, to the existing restconfig module as well. That would make
that module a mixture of the two systems.

I'm not particularly thrilled by either options... yes, I agreed with using
spring rest,
but that was for the geofence rules api, which is completely separate,
I did not know you were also working on a user/role one, nor did you
mention spring-ox.

As long as we can keep the new rest api separate I don't see a problem,
but I doubt you'll get any traction with a separate restconfig-ng module,
looks
like a big-bang rewrite is needed to make it actually replace the core
rest-config,
as I believe we need to keep everything config related in a single url tree
(the resources
are interconnected with each other), like, if we add a new type of
ResourceInfo (one based
on processes for example), we cannot really publish it in a different rest
url tree... it seems
to me only rest api that is not related to service and data config could be
moved to a
restconfig-ng, which would make it no config at all...

But maybe you though it out in detail and see a way to make it work, so
please elaborate

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[Niels_Charlier]

On 20-05-15 11:01, Andrea Aime wrote:

Not against it, but since it will create a ton of "tech debt", we need a proposal
and all devs to agree that from now all new restlets are going to be written
with Spring.
Also, how do you intend to keep the rest-config module working with
a mix of the two systems, can actually gradually migrate, or would
we have to rewrite all restconfig in a single shot?

The idea would be to have them next to each other for now. See below.

GeoServer heavily relies on XStream for that task, is this
another technology you're proposing as a replacement for the future?
I see that spring-oxm can use XStream, but does not look like it's the
recommended way, can you clarify?

Oxm is the integrated system used by the spring rest. You only add some annotations and spring takes care of everything, you can use the objects as input and output for your controllers without explicitly doing any conversion. There is a way to bridge the two systems: http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/oxm/xstream/XStreamMarshaller.html. The only non-recommendation regards security vulnerability when reading external sources, I'm not sure if that applies for us. Alternatively, we can migrate the concerned classes by adding annotations.

I'm not particularly thrilled by either options... yes, I agreed with using spring rest,
but that was for the geofence rules api, which is completely separate,
I did not know you were also working on a user/role one, nor did you mention spring-ox.

As long as we can keep the new rest api separate I don't see a problem,
but I doubt you'll get any traction with a separate restconfig-ng module, looks
like a big-bang rewrite is needed to make it actually replace the core rest-config,
as I believe we need to keep everything config related in a single url tree (the resources
are interconnected with each other), like, if we add a new type of ResourceInfo (one based
on processes for example), we cannot really publish it in a different rest url tree... it seems
to me only rest api that is not related to service and data config could be moved to a
restconfig-ng, which would make it no config at all...

But maybe you though it out in detail and see a way to make it work, so please elaborate

I see your point. I think it should be possible to create a SimpleUrlHandlerMapping that handles specific mappings on the same url tree and is checked before the general restlet one. Alternatively, the current restlet dispatcher may be extended to forward requests to spring controllers.

Regards
Niels

[Andrea_Aime4]

On Wed, May 20, 2015 at 12:14 PM, Niels Charlier <niels@anonymised.com> wrote:

GeoServer heavily relies on XStream for that task, is this

another technology you're proposing as a replacement for the future?
I see that spring-oxm can use XStream, but does not look like it's the
recommended way, can you clarify?

Oxm is the integrated system used by the spring rest. You only add some
annotations and spring takes care of everything, you can use the objects
as input and output for your controllers without explicitly doing any
conversion. There is a way to bridge the two systems:
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/oxm/xstream/XStreamMarshaller.html.
The only non-recommendation regards security vulnerability when reading
external sources, I'm not sure if that applies for us. Alternatively, we
can migrate the concerned classes by adding annotations.

Hum... it would be the fourth object <-> xml technology we have in the code
base (old xml parsers/encoders, xsd parsers encoders, xstream).

From what it looks this one is in the same basket as xstream.

I don't want to sound against innovation, but we cannot either allow
everybody to go their merry
way and keep on piling up dependencies and programming styles that in the
end just make
it harder to undestand, maintain and evolve the code.
So, for these cases, I'd like to hear a solid agreement from the community
if its usage
goes beyond a isolated case in a unsupported module.

But maybe you though it out in detail and see a way to make it work, so

please elaborate

I see your point. I think it should be possible to create a
SimpleUrlHandlerMapping that handles specific mappings on the same url tree
and is checked before the general restlet one. Alternatively, the current
restlet dispatcher may be extended to forward requests to spring
controllers.

I guess it might work, technically.
See my concerns about having having mixed technology, we need a shared
plan/direction if this
goes into core modules.

Cheers
Andrea

--

Meet us at the INSPIRE Conference in Lisbon 25-29 May 2015! Visit
http://goo.gl/WHKDXT for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[Niels_Charlier]

On 20-05-15 12:22, Andrea Aime wrote:

Hum... it would be the fourth object <-> xml technology we have in the code base (old xml parsers/encoders, xsd parsers encoders, xstream).
From what it looks this one is in the same basket as xstream.
I don't want to sound against innovation, but we cannot either allow everybody to go their merry
way and keep on piling up dependencies and programming styles that in the end just make
it harder to undestand, maintain and evolve the code.
So, for these cases, I'd like to hear a solid agreement from the community if its usage
goes beyond a isolated case in a unsupported module.

OXM is actually not an object<-->xml mapping technology, but an abstraction of this mapping that allows many implementations. This abstraction comes with using spring rest api, and is mainly there to support implicit conversion in your spring controllers.
The mapping implementation I used in geofence-server is actually called Jaxb. (The used xml annotations, by the way, are part of the java standard library.) Alternative implementations that can be used are xmlbeans, jibx OR xstream.
So, to summarize, in order to switch to spring rest there is no absolute necessity to add another technology like jaxb, but there is a need for OXM though which would function as the bridge between spring rest and xstream.

I think spring rest by itself is definitely an improvement in terms of "understand, maintain and evolve the code", although of course I agree that people can't just pile up new ways of doing things and agreement is necessary. I just picked up from Jody he was interested in switching to spring rest which is the main reason I suggested it. Also, geoserver already relies on spring so much that (apart from oxm) there is very little need for additional dependencies.

Either way, I was mainly trying to figure out what to do with my code. I guess if there is no agreement then by default the user/role api will remain part of the geofence-server community module as part of the geofence rest server and it will need to be implemented as a restful service to become part of geoserver.

Regards
Niels

[jive]

In the interest of making a milestone release I would prefer option (0). Any subsequent duplication/integration with GSIP-120 can take place when that work is ready?

With respect to REST API for users/groups - I was not aware of any progress on GSIP-120 - although now I see it was edited on April 19th. Perhaps we can get an update from Christian.

···

On 20 May 2015 at 01:38, Niels Charlier <niels@anonymised.com> wrote:

Hello,

While doing a pull request on the geofence-server rest api, I had a question. This rest api is made in the spring rest api, unlike the rest of geoserver which uses restful. Jody suggested we might wish to (gradually) move towards that system, and I prefer it as well, It is very easy to read and write.

Additionally to that, I have also made a rest api for user/groups and roles in the same fashion. The spring classes only rely on one additional dependency above the normal spring stuff, and that is spring-oxm (handles the xml to object conversions).

Now the user and role stuff doesn’t really belong in the geofence-server module, because people might want to use it if they are using the default security subsystem and not geofence. So currently these are the options:

(0) Leave the user/role spring rest api only for geofence-server users;
(1) My first proposal was to create a new community module rest-sec with all the common security rest api.
However, in the meantime Christian is making a rest api for security rules in the standard subsystem, and is doing this the traditional way with restful and adding it to the existing restconfig module, so that seems kind of off the table;
(2) My other proposal was to create a new module restconfig-ng that will hold all future spring rest api stuff, keeping the two systems separate as (if) we gradually move from one to the other.
(3) Simply add the user/role rest api classes, including the oxm dependency, to the existing restconfig module as well. That would make that module a mixture of the two systems.

Regards
Niels

–
Jody Garnett