Hi Andrea, Thanks for the comments, let me see how much I understand :)
Some comments inline below: > On 12 Oct 2017, at 14:11, Andrea Aime <[email protected]> wrote: > > Hi Tom, > I believe methods 2 and 3 both depend on TransactionPlugin, last time I > played around it > I opened this ticket: > > https://osgeo-org.atlassian.net/browse/GEOS-7403 > > Unless I'm wrong, since the introduction of WFS 2.0 support (and the > associated refactoring it > required) it is no longer possible to modify the transactions on the fly, > save one specific case of inserts. > I've managed to hack together a proof of concept with the python-scripting hooks that appears to be able to modify updates, doing something like: -- # ... def preUpdate(updated, props, req, context): from org.geotools.xml import EMFUtils from javax.xml.namespace import QName updateelement = req.getElements().get(0).getAdaptee() info('elem=%s'% str(updateelement)) for prop in updateelement.getProperty(): propname = prop.getName() propval = prop.getValue() info('>> name='+str(propname) + ' val=' + str(propval)) if propname.getLocalPart() == 'edited_by': prop.setValue('PONIES') # SecurityContextHolder.getContext().getAuthentication().getName() -- Of course, whether I *should* be poking around in the guts of UpdateElementType and similar is another question entirely. I've only tested with wfs 1.1.0 requests so far, since that's what the web-sdk/openlayers client appears to send (and I'm not sure if it can support wfs2). > About method 2, it relies on a module that is officially unsupported and has > seen its last actual > change over 3 years ago (the GEOS-6535 one): > > https://github.com/geoserver/geoserver/commits/master/src/community/script/py/src > Yeah, it did look a little bit stale, but it seems to still sort of work. > Among the various options I'd go for 3), but even that one requires some non > trivial fixes > in the WFS module to restore TransactionPlugin ability to modify the > transaction contents. > Going for 2) is also posssible of course, but TransactionPlugin needs fixing > first. > Is fixing TxnPlugin something I (as geoserver, and to some extent Big-Java-App newbie) could look at? If so, could you suggest where to start looking? (or which was the last version that it did still work properly?) > While I'm at it let me offer a method 5), which is, implementing a > DispatcherCallback > modifying the transaction request as it gets in. > It is similar to 3), but requires you to implement modification code for WFS > 1.0/1.1 and > WFS 2.0 request objects separately (they are both called TransactionType, but > live in two different packages). > If I'm looking at the right DispatcherCallback, then the Request/Operation args it receives are quite early in the processing/decoding chain, so I'd need to extract and identify the target layer, process the transaction items, and return a modified complete request for onward processing; essentially the HTTP Proxy suggestion, but inside the geoserver context so I can access some internals? If that's correct, it sounds like maybe more work than I'd prefer compared with the TransactionPlugin approach if I can make that happen. > About the fragily related to internal changes, you cannot eliminate it fully, > GeoServer > is managed as an application, not a library, so we care primarily about > backwards compatibility > for outside users, and then for extension point interfaces to some extent, > but the > rest is subject to change. That said, TransactionType did not change in a > long time, > so it's probably safe (but no promises! :-) ). > I'm leaning towards putting in a fairly thin shim plugin somewhere that extracts the transaction details for things I care about, sends it all to a remote service which will do all the fancy business-rule validation/modification, and insert the results from there back into the internal transaction. > Cheers > Andrea > <snip> -- Tom Feist-Hassan <[email protected]> Senior Engineer, MHN Ltd. 1.5 Techcube, Summerhall Edinburgh, EH9 1PL Company Registered in Scotland number SC304505 | 6 ATHOLL CRESCENT PERTH PH1 5JN ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
