Hi Justin,
Thanks. I forgot to mention that I had seen the TransactionPlugin
extension point; that one is awesome and I see how to use it support my
second suggestion.
Would changes in the GML2/3ParsingUtils to inject attributes into a
SimpleFeature's userData be sensible / more broadly useful? I'm a bit
shy about pushing hard for such a change since I am not sure about any
other ramifications.
Thanks,
Jim
On 04/08/2016 10:45 AM, Justin Deoliveira wrote:
Hey Jim,
The wfs native element might be the cleanest way to handle this. I’ve
seen folks use it before for security and validation type stuff with
some success. In GeoServer you can plug in WFS transactions callbacks
pretty easily using the TransactionPlugin
<[https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java]%28https://github.com/geoserver/geoserver/blob/master/src/wfs/src/main/java/org/geoserver/wfs/TransactionPlugin.java>
extension point. It has direct access to the transaction object which
has the native content on it.
If you do want to go with approach (1): during GML parsing I don’t
believe there is any way to tag a GML attribute as something you want
to store in user data. Folks might correct me on that one though. To
support it I wonder if we could do something simple like a custom
attribute on the gml attribute element. Something like:
|<ns:someAttribute userData=“true”>foo</ns:someAttribute> |
One potential downside might be validation… however in GeoServer last
I checked we don’t validate features on the way in… mostly because
it’s a pain to have to specify all the schema references properly so a
parser can actually validate. It may also be there in the gml schema
there is some attribute we might be able to use /abuse for this
purpose… I can’t think of one off hand though.
As far as I know the feature parsing logic still lives in the
GML3ParsingUtils and GML2ParsingUtils classes. To add some support for
putting an attribute in user data rather than a normal attribute I
think you would be looking at modifying this method
<[https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362]%28https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/bindings/GML2ParsingUtils.java#L338-L362>.
As you’ll notice this only applies to simple features. If working with
complex features i am actually not sure where that logic lives
anymore. One of the app-schema folks can point you at that if need be.
Hope that helps!
-Justin
On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jn...@ccri.com
<mailto:jn...@ccri.com>> wrote:
Hi all,
Apologies for the cross-post, but my question hits a little of how
GeoServer handles WFS transactions and a little bit of how
GeoTools may
handle WFS/GML parsing.
My high-level goal is to find a way to add security info to a WFS
transaction. I can see three big options: 1. add some bits to
the GML
feature / WFS call which would set a SimpleFeature's userData or
otherwise provide additional data, 2. leverage a WFS 'Native' tag,
or 3.
store the security info in the SimpleFeature.
I've got a pretty good handle on the last two options. The first
option
would provide the greatest flexibility, so I'm wondering if anyone can
help point me in the right direction there. (Or otherwise say
that this
is impossible without re-writing GT/GS XML handling...)
Thanks in advance,
Jim
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
