Sounds fine, safety is good.
···
On Fri, Oct 17, 2014 at 11:13 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
There is actually a dedicated interface you can implement named CatalogValidator, actually you’re the author of it 
The way the extension point is processed is a bit different though, it captures errors in a list rather than throw them back directly. So client code actually has to call the validate method first before calling add or save. It looks like some code does that in restconfig and in the ui, but not all. So one approach would be to add the validator, and also ensure that the appropriate validate methods are being called through the REST and Web interfaces.
A more core change would be to change CatalogImpl itself and have any validation methods be thrown back directly. To be honest I can’t remember why this wasn’t done in the first place.
One potential upside of the first approach is that it handles the migration seamlessly as the layer with the space in it’s name will be added to the catalog on startup without issue, and users will only encounter an issue (other than the issues with spaces being there in the first place) when they try to update it.
–
David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo
On Fri, Oct 17, 2014 at 8:53 AM, David Winslow <dwinslow@anonymised.com> wrote:
OK, sounds like there is a consensus on this issue. I’ll look into adding the validation to the catalog. For cases where existing configuration already violates this new constraint I suppose we need a migration strategy. Probably the simplest thing would be to just disable layers where the names are illegal, administrators would need to meet the new constraints before they could save the form to re-enable them. If we do some automated renaming there could be issues if some administrator has already added workspaces whose names only vary by xml-unsafe characters.
I don’t think that I have implemented any catalog-level validation before. Is the NamespaceWorkspaceConsistencyListener a good example to follow? I expect that throwing an exception in handleModified will prevent the save from going through.
–
Justin Deoliveira
VP Engineering | Boundless
jdeolive@anonymised.com
@boundlessgeo
On Fri, Oct 17, 2014 at 5:24 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
–
David Winslow
Software Engineer | Boundless
dwinslow@anonymised.com
917-388-9085
@boundlessgeo
On Thu, Oct 16, 2014 at 9:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
I am kind of thinking since there are so many issues regarding layer names with spaces (like they can’t used with wfs, etc…) that we simply disallow it across the board for consistency. I believe at the moment the UI validates layer names with such a constraint but nothing else does. I would advocate that we move the check into the Catalog itself with the rest of the validation checks and call it a day.
Agreed
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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.
