Hi Andrea, it would be time to
1) apply the patch
2) creating an offical subdir "geoxacml" in the web2 geoserver data dir.
Hi Christian,
What are your plans for moving your module to an extension or core? It would be nice if this was done before we start patching web.xml to handle the request mapping. That said, I understand that that is a big hurdle for such a small patch... so it is not a -1, just a comment/question.
An alternative would be to come up with a generic "/security" mapping in web.xml, and have your mapping declared in your applicationContext.xml, mapping it to "security/geoxaml". Not sure if this makes sense for you, but it would allow you to do your "routing" in your plugin, rather than in the core. Having a root "security" context would also make sense if we foresee future security plugins which will have servlets/controllers similar to the geoxacml one.
2c,
-Justin
Christian Müller wrote:
Hi Andrea, it would be time to
1) apply the patch
2) creating an offical subdir "geoxacml" in the web2 geoserver data dir.------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
The approach with the generic "security" mapping in web.xml is ok for me. I only want to get rid of this patch file.
If we use the geoxacml component for geoserver itself (this is the intension), then, I think, it must be a core component.
I urgently need the geoxamcl sub folder in the geoserver data dir (web2), otherwise I get some chaos into the implementation. This directory contains some predefined policy files, for the test cases I have to copy additional files into that directory.
At the moment I must hold the default policy files in my resource folder, which makes the job not easier.
Last not least, Andrea has to agree on this because he is my mentor 
(Ahh, and btw, the project lead)
Justin Deoliveira writes:
Hi Christian,
What are your plans for moving your module to an extension or core? It would be nice if this was done before we start patching web.xml to handle the request mapping. That said, I understand that that is a big hurdle for such a small patch... so it is not a -1, just a comment/question.
An alternative would be to come up with a generic "/security" mapping in web.xml, and have your mapping declared in your applicationContext.xml, mapping it to "security/geoxaml". Not sure if this makes sense for you, but it would allow you to do your "routing" in your plugin, rather than in the core. Having a root "security" context would also make sense if we foresee future security plugins which will have servlets/controllers similar to the geoxacml one.
2c,
-Justin
Christian Müller wrote:
Hi Andrea, it would be time to
1) apply the patch
2) creating an offical subdir "geoxacml" in the web2 geoserver data dir.------------------------------------------------------------------------- -----
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Christian Müller wrote:
The approach with the generic "security" mapping in web.xml is ok for me. I only want to get rid of this patch file.
If we use the geoxacml component for geoserver itself (this is the intension), then, I think, it must be a core component.
I urgently need the geoxamcl sub folder in the geoserver data dir (web2), otherwise I get some chaos into the implementation. This directory contains some predefined policy files, for the test cases I have to copy additional files into that directory.
I appreciate your need for urgency, but showing a little patience is appreciated in such matters. A bit of thinking up front can save a lot of work down the road.
At the moment I must hold the default policy files in my resource folder, which makes the job not easier.
Last not least, Andrea has to agree on this because he is my mentor
(Ahh, and btw, the project lead)
We don't follow a benevolent dictator model of project management in GeoServer so such decisions are made by the PSC as a group. So regardless of anyones "role" on the project they do not get any more voice than anyone else. But yes, Andrea as your mentor naturally has a better understanding here so I (as i am sure will others) will happily delegate to him on this one.
Justin Deoliveira writes:
Hi Christian,
What are your plans for moving your module to an extension or core? It would be nice if this was done before we start patching web.xml to handle the request mapping. That said, I understand that that is a big hurdle for such a small patch... so it is not a -1, just a comment/question.
An alternative would be to come up with a generic "/security" mapping in web.xml, and have your mapping declared in your applicationContext.xml, mapping it to "security/geoxaml". Not sure if this makes sense for you, but it would allow you to do your "routing" in your plugin, rather than in the core. Having a root "security" context would also make sense if we foresee future security plugins which will have servlets/controllers similar to the geoxacml one.
2c,
-Justin
Christian Müller wrote:
Hi Andrea, it would be time to
1) apply the patch
2) creating an offical subdir "geoxacml" in the web2 geoserver data dir.------------------------------------------------------------------------- -----
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Christian Müller ha scritto:
Apologies for the late reply on this topic 
The approach with the generic "security" mapping in web.xml is ok for me. I only want to get rid of this patch file.
A generic security setup + url mapping in the context files works just fine for me as well.
If we use the geoxacml component for geoserver itself (this is the intension), then, I think, it must be a core component.
Not so fast. GEOXACML is a very complicated way to setup security,
so imho it should be plugin instead. People needing basic security
can keep on using the old subsystem which does not require heavy
xml handling and already has an (almost complete) UI in the web-security
community module.
I can go for having GEOAXCML become the default in time if we can
make it as easy to use as the old one for the simple case (pay as you
go approach). But first it has to prove itself, be used as an extension
for some time and see some production usage.
I urgently need the geoxamcl sub folder in the geoserver data dir (web2), otherwise I get some chaos into the implementation. This directory contains some predefined policy files, for the test cases I have to copy additional files into that directory.
There is an easy workaround for this that is already used in many other
GeoServer places: have your geoaxcml plugin keep default config files in
the classpath, and copy them over to the data directory when they are
first needed, if the data dir does not contain them (along with the
directories needed in the config, of course).
This is what every well behaved extension in need of configuration files
should do (we cannot have data dirs taking care or the needs of every
possible extension and community module by default, it would turn into
a mess).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.