[Geoserver-devel] [jira] Created: (GEOS-3444) java.lang.OutOfMemoryError with restconfig plugin

2009-09-11 Thread Tim Schaub (JIRA) 
java.lang.OutOfMemoryError with restconfig plugin
-

 Key: GEOS-3444
 URL: http://jira.codehaus.org/browse/GEOS-3444
 Project: GeoServer
  Issue Type: Bug
  Components: WMS
 Environment: Mac OSX
Reporter: Tim Schaub
Assignee: Andrea Aime


Using the restconfig plugin from 
http://gridlock.openplans.org/geoserver/trunk/ext-2009-09-11/ and the 
corresponding GeoServer nightly, I can somewhat regularly get out of memory 
errors on WMS GetMap requests.  It looks like this only happens after making 
requests to /geoserver/rest/styles.

To reproduce, I run the styler app, change layers several times and pan around 
a bit.  Usually I can see the exceptions in returned image tiles.  The trace 
looks something like the following:

{code}
11 Sep 20:14:00 ERROR [geoserver.ows] - 
java.lang.OutOfMemoryError: Java heap space
at java.awt.image.DataBufferByte.(DataBufferByte.java:42)
at java.awt.image.Raster.createInterleavedRaster(Raster.java:253)
at java.awt.image.BufferedImage.(BufferedImage.java:385)
at 
org.vfny.geoserver.wms.responses.ImageUtils.createImage(ImageUtils.java:83)
at 
org.vfny.geoserver.wms.responses.DefaultRasterMapProducer.prepareImage(DefaultRasterMapProducer.java:554)
at 
org.vfny.geoserver.wms.responses.DefaultRasterMapProducer.produceMap(DefaultRasterMapProducer.java:252)
at 
org.vfny.geoserver.wms.responses.map.metatile.MetatileMapProducer.produceMap(MetatileMapProducer.java:122)
at 
org.vfny.geoserver.wms.responses.GetMapResponse.execute(GetMapResponse.java:421)
at 
org.geoserver.ows.adapters.ResponseAdapter.getMimeType(ResponseAdapter.java:48)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:699)
at 
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:216)
at 
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at 
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at 
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
at 
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at 
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at 
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at 
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:124)
at 
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at 
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at 
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
at 
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-3443) 500 error on resource name collision through REST API

2009-09-11 Thread Sebastian Benthall (JIRA) 
500 error on resource name collision through REST API
-

 Key: GEOS-3443
 URL: http://jira.codehaus.org/browse/GEOS-3443
 Project: GeoServer
  Issue Type: Bug
  Components: REST
Affects Versions: 2.0-RC1
Reporter: Sebastian Benthall
Assignee: Justin Deoliveira


When you use the REST API to change a resource's name, and pick a name that is 
already used by another resource, you get a 500 error in response.

sbenthall: What if there is a layer name collision?
jdeolive: The current implementation will return a 500. But this is a bug. It 
should handle this case and return a 403.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-3442) Validation on Keywords for PUTing resources through REST api

2009-09-11 Thread Sebastian Benthall (JIRA) 
Validation on Keywords for PUTing resources through REST api


 Key: GEOS-3442
 URL: http://jira.codehaus.org/browse/GEOS-3442
 Project: GeoServer
  Issue Type: Improvement
  Components: REST
Affects Versions: 2.0-RC1
Reporter: Sebastian Benthall
Assignee: Andrea Aime
 Attachments: request.txt

In the request described in the attachment, I have successfully (200) set the 
'keywords' metadata field on the bugsites resource to "not a list."  When I 
request the resource again, there is no 'keywords' field in the returned JSON.

It would be nice to have GeoServer validate the keywords field to warn the user 
that they have done something wrong.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-3441) Validation on SRS for PUTing resources through REST api

2009-09-11 Thread Sebastian Benthall (JIRA) 
Validation on SRS for PUTing resources through REST api
---

 Key: GEOS-3441
 URL: http://jira.codehaus.org/browse/GEOS-3441
 Project: GeoServer
  Issue Type: Improvement
  Components: REST
Affects Versions: 2.0-RC1
Reporter: Sebastian Benthall
Assignee: Andrea Aime
 Attachments: request

Attached request sends JSON to the REST API to change the metadata of the 
bugsites layer and gets a 200 back with no complaint.

The problem is that the request sets the layer's 'srs' field to 'mightymouse'.

It would be nice if GeoServer let the user know that something was amiss here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-3440) Default data dir does not survive a restart

2009-09-11 Thread David Winslow (JIRA) 
Default data dir does not survive a restart
---

 Key: GEOS-3440
 URL: http://jira.codehaus.org/browse/GEOS-3440
 Project: GeoServer
  Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: David Winslow
Assignee: Justin Deoliveira


I'm using the default data directory via the jetty:run Maven task, with the 
following command:
{code}
$ mvn jetty:run -DGEOSERVER_DATA_DIR=/home/dwins/gs-release-data/ 
-Prestconfig,geosearch
{code}

Starting from a fresh copy of the data dir (an unmodified copy of what's in 
SVN, using svn export), I get the following:
{code}
$ curl http://localhost:8080/geoserver/rest/workspaces/default.json
{"workspace":{"name":"topp","dataStores":"http:\/\/localhost:8080\/geoserver\/rest\/workspaces\/default\/datastores.json","coverageStores":"http:\/\/localhost:8080\/geoserver\/rest\/workspaces\/default\/coveragestores.json"}}
{code}

If I then restart and try again, I get something different: 
{code}
$ curl http://localhost:8080/geoserver/rest/workspaces/default.json
{"workspace":{"name":"nurc","dataStores":"http:\/\/localhost:8080\/geoserver\/rest\/workspaces\/default\/datastores.json","coverageStores":"http:\/\/localhost:8080\/geoserver\/rest\/workspaces\/default\/coveragestores.json"}}
{code}

Further restarts do not seem to keep changing the default workspace, so perhaps 
this is an issue with the data directory conversion code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Hudson build is back to normal: geoserver-trunk #1756

2009-09-11 Thread Hudson 
See 



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Rest Routing Improvements

2009-09-11 Thread David Winslow 
On Fri, 2009-09-11 at 11:57 -0400, David Winslow wrote:
> On Fri, 2009-09-11 at 12:20 +0200, Andrea Aime wrote:
> > David Winslow ha scritto:
> > > However, Restlet also provides "types" for the variables in templates,
> > > which we have thus far ignored, meaning all variables in templates are
> > > using the default type, URI_SEGMENT.  However, there are further
> > > restrictions that might be useful (digit sequences for example) and
> > > relaxations that definitely would be handy, especially in light of
> > > requiring full matches.  We would require this to, for example, provide
> > > a service that exposes XML documents as arbitrary-depth hierarchies.
> > > 
> > > This requires calling mutator function on the Route object created when
> > > Router.attach is called.  The function takes a map
> > > from name to variable specification, so we'd need to either set up an
> > > encoding for these in spring, or expose an extension point allowing
> > > routings to customize the Routes they generate.
> > 
> > Ok, I'm officially lost :-)
> > Where can I read more about this topic?
> 
> I linked to the Javadocs for org.restlet.util.Variable on the ticket;
> the Route and Template docs are also relevant.  I'm not aware of any
> more in-depth documentation on them.
> 
> http://www.restlet.org/documentation/1.0/api/org/restlet/util/Variable.html
> http://www.restlet.org/documentation/1.0/api/org/restlet/util/Template.html
> http://www.restlet.org/documentation/1.0/api/org/restlet/Route.html
> 
> Basically, for each path/restlet pair in the code, we call
> Router.attach(path, restlet);
> which returns a Route for further manipulation, but we ignore it now.
> For the variable-related changes, we'd need to do:
> Route r = router.attach(path, restlet);
> r.getTemplate().setMatchingMode(Template.MODE_EQUALS);
> r.getTemplate().setVariables(somemapofnamestovariables);
> 
> > I'm wondering if we can get to a compromise here that does not
> > force us to use heavy syntax in all cases.
> > Something like {script} is assumed to be a plain string without "/"
> > inside of it if nothing else is stated.
> > And then have the map just to declare what is the expected type.
> 
> > A pay as you go model. I think in the majority of cases our variables
> > are non uri portion strings and they default to null?
> > For this case I would prefer not to have to specify anything (would
> > also make for backwards compatible approach, as we just add an
> > optional property to the mix)
> > 
> > Cheers
> > Andrea
> 
> I agree, it doesn't make sense to require a variable descriptor for
> variables that are fine with the default configuration.  It is probably
> also fine to have a shared variable map for all routes, but then it is
> essential that developers use variable names consistently in a set of
> routes.  I am also unsure whether restlet chokes on variable descriptors
> for variables that aren't in the route (stranger things have happened).
> I will investigate later today.
> 
> --
> David Winslow
> OpenGeo - http://opengeo.org/
> 

I just ran some tests (I was slowed down a bit by some problems with the
URL mangler but aaime fixed them before I even figured out what was
wrong :) and it looks like having superfluous variable descriptors
doesn't cause any problems.   So, I am +1 on having a single variable
map shared for all routes in a RESTMapping instance.  I'd be happy to
put together a patch, but I think I'll hold off on doing so until #3436
is closed.

--
David Winslow
OpenGeo - http://opengeo.org/


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #1755

2009-09-11 Thread Hudson 
See 

Changes:

[aaime] Declare service method as per recent change in the dispatcher

--
[...truncated 22986 lines...]




Olivine basalt
New Group
-Xy



Red




z






name_a
name_b
name_c




name_2




significant


interbedded component








Tests run: 7, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 5.155 sec <<< 
FAILURE!
Running org.geoserver.test.XYGeomTest
Sep 11, 2009 3:42:33 PM org.geoserver.test.FeatureChainingWfsTest 
testFilteringXlinkHref
INFO: WFS filter GetFeature response:

http://example.com"; xmlns:gml="http://www.opengis.net/gml";
xmlns:gsml="http://www.cgi-iugs.org/xml/GeoSciML/2";
xmlns:ogc="http://www.opengis.net/ogc";
xmlns:ows="http://www.opengis.net/ows";
xmlns:wfs="http://www.opengis.net/wfs";
xmlns:xlink="http://www.w3.org/1999/xlink";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://www.opengis.net/wfs 
http://localhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd 
http://www.cgi-iugs.org/xml/GeoSciML/2 
http://localhost:80/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=gsml%3AMappedFeature";>


GUNTHORPE FORMATION


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.2 52.5 -1.2 52.6 -1.1 52.6 -1.1 
52.5 -1.2 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py



Blue




x






significant


interbedded component






MERCIA MUDSTONE GROUP


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.3 52.5 -1.3 52.6 -1.2 52.6 -1.2 
52.5 -1.3 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py




Yellow




Blue




y




x






significant


interbedded component

[Geoserver-devel] Sol Katz Award for Geospatial Free and Open Source Software - Call for Nominations

2009-09-11 Thread sophia parafina 
The Open Source Geospatial Foundation would like to open nominations for the
2009 Sol Katz Award for Geospatial Free and Open Source Software.

The Sol Katz Award for Geospatial Free and Open Source Software (GFOSS) will
be given to individuals who have demonstrated leadership in the GFOSS
community. Recipients of the award will have contributed significantly
through their activities to advance open source ideals in the geospatial
realm.

Nominations for the Sol Katz Award should be sent to
solkatzaw...@osgeo.orgwith a description of the reasons for this
nomination. Nominations will be
accepted until midnight UTC on October 9th. A recipient will be decided from
the nomination list by an OSGeo designated selection committee.

The winner of the Sol Katz Award for Geospatial Free and Open Source
Software will be announced on October 23rd at the FOSS4G 2009 conference
closing plenary in Sydney, Australia. The hope is that the award will both
acknowledge the work of community members, and pay tribute to one of its
founders, for years to come.

It should be noted that past awardees and selection committee members are
not eligible.

Full article .
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] A note on build failures due to url mangler changes (url encoding and decoding)

2009-09-11 Thread Andrea Aime 
Hi,
the build failure you've seen is due to the URL manglers GSIP
and me not checking the app schema module.

The issue there is that the new ResponseUtils.buildURL method
does actually url-encode all kvp parameters.
And this is a good thing, right?

Well, yeah, but it turns out we used to put in the various
URL we generated characters like the comma or the column that
are actually reserved chars which are not supposed to be found
in a URL, see here:
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
http://www.permadi.com/tutorial/urlEncoding/
http://en.wikipedia.org/wiki/Percent-encoding

and there is an online url encoder, decoder:
http://www.albionresearch.com/misc/urlencode.php

So, if I'm not reading the above documents wrong, the
current behavior is correct and some tests needed to
be fixed and url-decode the urls contained in our xml documents
before trying to split them on "," or checking equality with strings 
containing a column.

I'm still a bit surprised about this finding but...
here it goes.

If you know more about this topic and care to share it I'll be all ears

Cheers
Andrea


-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer and web filters

2009-09-11 Thread Gabriel Roldan 
Andrea Aime wrote:
> Gabriel Roldan ha scritto:
>> big +1 here too.
>>
>> Andrea, could you briefly explain to the list why 
>> DelegatingFilterProxy is not up to the task and hence the need for a 
>> home made solution?
> 
> Sure: the thing takes just one delegate, by name, whilst
> we need to delegate to a list, sort it to get proper ordering, and the
> list is unknown until startup

thanks :)
Gabriel
> 
> Cheers
> Andrea
> 


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer and web filters

2009-09-11 Thread Andrea Aime 
Gabriel Roldan ha scritto:
> big +1 here too.
> 
> Andrea, could you briefly explain to the list why DelegatingFilterProxy 
> is not up to the task and hence the need for a home made solution?

Sure: the thing takes just one delegate, by name, whilst
we need to delegate to a list, sort it to get proper ordering, and the
list is unknown until startup

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer and web filters

2009-09-11 Thread Gabriel Roldan 
big +1 here too.

Andrea, could you briefly explain to the list why DelegatingFilterProxy 
is not up to the task and hence the need for a home made solution?

cheers,
Gabriel
Justin Deoliveira wrote:
> A big +1 here. Now if only we could do the same trick with servlet 
> mapping paths we would be golden :)
> 
> Andrea Aime wrote:
>> Hi,
>> another discussion topic for the fry: plugabble web filters.
>> These things have been an annoyance for quite some time to me
>> for a very simple reason: they have to be declared in the
>> web.xml explicitly, thus they are not pluggable and require
>> some uglier than necessary code to participate in the
>> Spring context.
>>
>> I would really like to have those filters be pluggable things
>> instead, as in declared in the Spring context.
>> Imho it would make for a number of advantages:
>> - all the code related to a certain functionality is put
>>in the same module. For example now we have the security
>>stuff mixed between main and web-app
>> - the filters declared this way would be pluggable, no need
>>to hack the web-app module if you need to add custom
>>filtering, just drop your jar and be happy
>> - the filters could get all the dependencies via dependency
>>injection once
>> - the filters could be moved into some core module and
>>wire there, or just declared in web-app but without having
>>the classes there, so that making an alternate web-app
>>module becomes a matter of copying the pom and setting
>>the dependencies (think of a headless web setup with only
>>restconfig, or a custom pure wfs module, or stuff like that).
>>
>> Looking in Spring I've found this  "DelegatingFilterProxy"
>> class that allows to register just one bean filter and delegate
>> it to a bean that implements Filter and it's registered in the app
>> context.
>>
>> What I would like to do is to do soemthing along those lines,
>> a similar class that is registered as the one and only
>> filter in web.xml, and that:
>> - scans the Spring context to lookup for pluggable filters
>> - sort them according to the priority declared via implementation
>>of the ExtensionPriority interface
>> - applies them in order. Each filter is responsible to decide
>>whether to do something on a certain path, or not
>>(or if you prefer we can keep the path in which the filter
>> is to be applied)
>>
>> Thoughts?
>> Cheers
>> Andrea
>>
> 
> 


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Rest Routing Improvements

2009-09-11 Thread David Winslow 
On Fri, 2009-09-11 at 12:20 +0200, Andrea Aime wrote:
> David Winslow ha scritto:
> > However, Restlet also provides "types" for the variables in templates,
> > which we have thus far ignored, meaning all variables in templates are
> > using the default type, URI_SEGMENT.  However, there are further
> > restrictions that might be useful (digit sequences for example) and
> > relaxations that definitely would be handy, especially in light of
> > requiring full matches.  We would require this to, for example, provide
> > a service that exposes XML documents as arbitrary-depth hierarchies.
> > 
> > This requires calling mutator function on the Route object created when
> > Router.attach is called.  The function takes a map
> > from name to variable specification, so we'd need to either set up an
> > encoding for these in spring, or expose an extension point allowing
> > routings to customize the Routes they generate.
> 
> Ok, I'm officially lost :-)
> Where can I read more about this topic?

I linked to the Javadocs for org.restlet.util.Variable on the ticket;
the Route and Template docs are also relevant.  I'm not aware of any
more in-depth documentation on them.

http://www.restlet.org/documentation/1.0/api/org/restlet/util/Variable.html
http://www.restlet.org/documentation/1.0/api/org/restlet/util/Template.html
http://www.restlet.org/documentation/1.0/api/org/restlet/Route.html

Basically, for each path/restlet pair in the code, we call
Router.attach(path, restlet);
which returns a Route for further manipulation, but we ignore it now.
For the variable-related changes, we'd need to do:
Route r = router.attach(path, restlet);
r.getTemplate().setMatchingMode(Template.MODE_EQUALS);
r.getTemplate().setVariables(somemapofnamestovariables);

> I'm wondering if we can get to a compromise here that does not
> force us to use heavy syntax in all cases.
> Something like {script} is assumed to be a plain string without "/"
> inside of it if nothing else is stated.
> And then have the map just to declare what is the expected type.

> A pay as you go model. I think in the majority of cases our variables
> are non uri portion strings and they default to null?
> For this case I would prefer not to have to specify anything (would
> also make for backwards compatible approach, as we just add an
> optional property to the mix)
> 
> Cheers
> Andrea

I agree, it doesn't make sense to require a variable descriptor for
variables that are fine with the default configuration.  It is probably
also fine to have a shared variable map for all routes, but then it is
essential that developers use variable names consistently in a set of
routes.  I am also unsure whether restlet chokes on variable descriptors
for variables that aren't in the route (stranger things have happened).
I will investigate later today.

--
David Winslow
OpenGeo - http://opengeo.org/



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #1754

2009-09-11 Thread Hudson 
See 

Changes:

[francesco.izzi] Now you can manage the perLayerSecurity through the user 
interface

--
[...truncated 23014 lines...]




Olivine basalt
New Group
-Xy



Red




z






name_a
name_b
name_c




name_2




significant


interbedded component








Sep 11, 2009 12:42:28 PM org.geoserver.test.FeatureChainingWfsTest 
testFilteringXlinkHref
INFO: WFS filter GetFeature response:

http://example.com"; xmlns:gml="http://www.opengis.net/gml";
xmlns:gsml="http://www.cgi-iugs.org/xml/GeoSciML/2";
xmlns:ogc="http://www.opengis.net/ogc";
xmlns:ows="http://www.opengis.net/ows";
xmlns:wfs="http://www.opengis.net/wfs";
xmlns:xlink="http://www.w3.org/1999/xlink";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://www.opengis.net/wfs 
http://localhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd 
http://www.cgi-iugs.org/xml/GeoSciML/2 
http://localhost:80/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=gsml%3AMappedFeature";>


GUNTHORPE FORMATION


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.2 52.5 -1.2 52.6 -1.1 52.6 -1.1 
52.5 -1.2 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py



Blue




x






significant


interbedded component






MERCIA MUDSTONE GROUP


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.3 52.5 -1.3 52.6 -1.2 52.6 -1.2 
52.5 -1.3 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py




Yellow




Blue




y




x






significant


interbedded component






minor

[Geoserver-devel] 2.0-RC2 release

2009-09-11 Thread Justin Deoliveira 
Howdy folks,

2.0-RC2 is scheduled for next week. So I wanted to send out the notice 
to get commits in in the next couple of days. Getting changes in today 
would be ideal, but the warning is late, so perhaps today and Monday, 
starting the release train on Tuesday? Or does anyone require more time?

-Justin

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer and web filters

2009-09-11 Thread Justin Deoliveira 
A big +1 here. Now if only we could do the same trick with servlet 
mapping paths we would be golden :)

Andrea Aime wrote:
> Hi,
> another discussion topic for the fry: plugabble web filters.
> These things have been an annoyance for quite some time to me
> for a very simple reason: they have to be declared in the
> web.xml explicitly, thus they are not pluggable and require
> some uglier than necessary code to participate in the
> Spring context.
> 
> I would really like to have those filters be pluggable things
> instead, as in declared in the Spring context.
> Imho it would make for a number of advantages:
> - all the code related to a certain functionality is put
>in the same module. For example now we have the security
>stuff mixed between main and web-app
> - the filters declared this way would be pluggable, no need
>to hack the web-app module if you need to add custom
>filtering, just drop your jar and be happy
> - the filters could get all the dependencies via dependency
>injection once
> - the filters could be moved into some core module and
>wire there, or just declared in web-app but without having
>the classes there, so that making an alternate web-app
>module becomes a matter of copying the pom and setting
>the dependencies (think of a headless web setup with only
>restconfig, or a custom pure wfs module, or stuff like that).
> 
> Looking in Spring I've found this  "DelegatingFilterProxy"
> class that allows to register just one bean filter and delegate
> it to a bean that implements Filter and it's registered in the app
> context.
> 
> What I would like to do is to do soemthing along those lines,
> a similar class that is registered as the one and only
> filter in web.xml, and that:
> - scans the Spring context to lookup for pluggable filters
> - sort them according to the priority declared via implementation
>of the ExtensionPriority interface
> - applies them in order. Each filter is responsible to decide
>whether to do something on a certain path, or not
>(or if you prefer we can keep the path in which the filter
> is to be applied)
> 
> Thoughts?
> Cheers
> Andrea
> 


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #1753

2009-09-11 Thread Hudson 
See 

Changes:

[aaime] GSIP 39: pluggable url manglers

[francesco.izzi] add bean definition for 
org.geoserver.security.ServiceAccessRuleDAO (Andrea told me that I could 
committ)

--
[...truncated 23049 lines...]




Olivine basalt
New Group
-Xy



Red




z






name_a
name_b
name_c




name_2




significant


interbedded component








Sep 11, 2009 11:42:39 AM org.geoserver.test.FeatureChainingWfsTest 
testFilteringXlinkHref
INFO: WFS filter GetFeature response:

http://example.com"; xmlns:gml="http://www.opengis.net/gml";
xmlns:gsml="http://www.cgi-iugs.org/xml/GeoSciML/2";
xmlns:ogc="http://www.opengis.net/ogc";
xmlns:ows="http://www.opengis.net/ows";
xmlns:wfs="http://www.opengis.net/wfs";
xmlns:xlink="http://www.w3.org/1999/xlink";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://www.opengis.net/wfs 
http://localhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd 
http://www.cgi-iugs.org/xml/GeoSciML/2 
http://localhost:80/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=gsml%3AMappedFeature";>


GUNTHORPE FORMATION


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.2 52.5 -1.2 52.6 -1.1 52.6 -1.1 
52.5 -1.2 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py



Blue




x






significant


interbedded component






MERCIA MUDSTONE GROUP


http://urn.opengis.net";>urn:ogc:def:nil:OGC::missing






-1.3 52.5 -1.3 52.6 -1.2 52.6 -1.2 
52.5 -1.3 52.5






Olivine basalt, tuff, microgabbro, minor 
sedimentary rocks
Yaugher Volcanic 
Group
-Py




Yellow




Blue




y




x






significant


interbedded component

[Geoserver-devel] GeoServer and web filters

2009-09-11 Thread Andrea Aime 
Hi,
another discussion topic for the fry: plugabble web filters.
These things have been an annoyance for quite some time to me
for a very simple reason: they have to be declared in the
web.xml explicitly, thus they are not pluggable and require
some uglier than necessary code to participate in the
Spring context.

I would really like to have those filters be pluggable things
instead, as in declared in the Spring context.
Imho it would make for a number of advantages:
- all the code related to a certain functionality is put
   in the same module. For example now we have the security
   stuff mixed between main and web-app
- the filters declared this way would be pluggable, no need
   to hack the web-app module if you need to add custom
   filtering, just drop your jar and be happy
- the filters could get all the dependencies via dependency
   injection once
- the filters could be moved into some core module and
   wire there, or just declared in web-app but without having
   the classes there, so that making an alternate web-app
   module becomes a matter of copying the pom and setting
   the dependencies (think of a headless web setup with only
   restconfig, or a custom pure wfs module, or stuff like that).

Looking in Spring I've found this  "DelegatingFilterProxy"
class that allows to register just one bean filter and delegate
it to a bean that implements Filter and it's registered in the app
context.

What I would like to do is to do soemthing along those lines,
a similar class that is registered as the one and only
filter in web.xml, and that:
- scans the Spring context to lookup for pluggable filters
- sort them according to the priority declared via implementation
   of the ExtensionPriority interface
- applies them in order. Each filter is responsible to decide
   whether to do something on a certain path, or not
   (or if you prefer we can keep the path in which the filter
is to be applied)

Thoughts?
Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-3439) Backport pluggable URL manglers GSIP to 1.7.x

2009-09-11 Thread Andrea Aime (JIRA) 
Backport pluggable URL manglers GSIP to 1.7.x
-

 Key: GEOS-3439
 URL: http://jira.codehaus.org/browse/GEOS-3439
 Project: GeoServer
  Issue Type: Task
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 1.7.7


As stated in the GSIP itself, it is targeted for 1.7.x as well

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] review practices

2009-09-11 Thread Justin Deoliveira 
All great points Andrea. Some comments inline.

Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> Lately there has been a lot of talk around review practices. And in 
>> general review is something that has becoming more frequent (which I 
>> think is a great thing).
> 
> I guess one background question that we need to agree upon is:
> do we want to raise the code quality and is software reviews the
> way to get there?
> I'm +1 on this, but given reviews take work, we need the commitment
> of everybody else too.
> 
>> However, without an official policy in place review has been ambiguous, 
>> with some people wondering when they need a review, etc...
>>
>> So in an effort to rectify this I would like to come up with a code 
>> review policy in GeoServer. I have put together a wiki page to foster 
>> discussion:
>>
>> http://geoserver.org/display/GEOS/Review+Practices
>>
>> It needs to be expanded in a couple of places. After everyone weighs in 
>> we can put together the official GSIP and update the developer guide.
> 
> Some opinions:
> - I would say, let's just mandate pre-commit review on the bigger stuff.
>No post commit review as a rule, thought people is invited to keep
>an eye on what other developers are doing and try to be helpful.
Just to state my preference I would prefer pre-comit review as well.
> - who reviews what... stingy one.
>I'd say let's nominate module maintainers, but make sure we have at
>least two official maintainers per core module (if we get more,
>even better) so that they can review each other.
>The maintainer concept should be not as strong as in GeoTools imho,
>it should be more of a reviewing responsibility than "this is my
>module and I do whatever I please with it".
Perhaps we should just call this role "reviewer", rather than 
"maintainer" to make it more explicit.
> - what makes for big enough patches? Ha :-)
>I'd say every new feature is big enough, no matter how small (that is,
>the quality of the patch makes it review worthy, not much its size)
>For bug fixes hmmm there are small ones and bigger ones for sure.
>Some may be 10 lines with a patch outside of main/ows/platform, I
>would not feel like asking review for those (small enough to be
>understandable by looking at the commit list I'd say).
>Some require reworking a group of classes, or it's code that is
>used in a lot of places (stuff in main/ows), a review would be
>advisable. Especially in main/ows changes a look at the patch
>from whoever maintains affected modules is advisable (but
>not mandatory).
I agree here, but it is still a blurry line as to what needs to be 
reviewed and what does not. I think I would push for any change to a 
core module has to be reviewed, unless undeniably trivial. And in 
non-core modules we trust the person applying the patch to make the 
call, trying to provide as many guidelines as we can.

> 
> One thing that worries me about reviews is developer getting
> stuck waiting for a review, be frustrated, move to something else.
> We have to avoid that at all costs imho.
> I would like to see the following:
> - when there is a need for a review it should become the
>highest priority for the other developers. At least, saying
>"I'll review this" should be something that pops up within
>the day (having somone that declares he'll do the review should
>happen quickly)
> - the review itself should be taken care of quickly. No more
>than a week delay imho unless the patch is really huge.
> What I mean is that the review system should flow like clear
> water, if developers start feeling stuck like in quicksands
> we have a problem (a serious one).
Agreed, there should be some time limit on a review. Ideally something 
in proportion to the size of the patch. I mean... the initial app-schema 
patch I reviewed was huge, doing it on one week would have been a bit 
tough, especially since it involved actually applying and doing testing.

I know this is a very special case, but still putting a hard number 
leaves the back door open. One week also may not be ideal in cases where 
a developer has to take a leave of some sort, and is the primary reviewer.

What about this: We call the time limit one week to review, unless:

a) the patch is too big to review in a week
b) the reviewer has asked for and obtained more time from the submitter 
for the review

Now, let's say after a week nothing has been reviewed. I would say the 
original submitter can apply the patch without review, *but*, posts the 
patch for post-commit review in crucible or whatever tool we adopt.

This way the developer is not held up, but the code still has a chance 
to be reviewed. If no review happens, it is the fault of the reviewer.

> 
> Another very important thing is that we should have guidelines
> on how a review should be approached. Nothing big, just
> a good read to avoid reviews becoming dogfights over

Re: [Geoserver-devel] review practices

2009-09-11 Thread Rob Atkinson 
I agree with Andrea's perspective.

Its a tricky balancing act.

the thing that worries me a little is the process of assigning module
maintainers - either a few people get it all, and wont be able to keep
up with review load, or many people, and its hard to keep track of
who's actually active, or no maintainer is assigned - its a matter of
finding someone who cares.

I wonder if module dependency can help - you get some review
responsibility for a package if you use it, if there is no other
maintainer already assigned? So people who manage a "leaf" module need
to help with the things they care about?

Rob


On Fri, Sep 11, 2009 at 7:47 PM, Andrea Aime  wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> Lately there has been a lot of talk around review practices. And in
>> general review is something that has becoming more frequent (which I
>> think is a great thing).
>
> I guess one background question that we need to agree upon is:
> do we want to raise the code quality and is software reviews the
> way to get there?
> I'm +1 on this, but given reviews take work, we need the commitment
> of everybody else too.
>
>> However, without an official policy in place review has been ambiguous,
>> with some people wondering when they need a review, etc...
>>
>> So in an effort to rectify this I would like to come up with a code
>> review policy in GeoServer. I have put together a wiki page to foster
>> discussion:
>>
>> http://geoserver.org/display/GEOS/Review+Practices
>>
>> It needs to be expanded in a couple of places. After everyone weighs in
>> we can put together the official GSIP and update the developer guide.
>
> Some opinions:
> - I would say, let's just mandate pre-commit review on the bigger stuff.
>   No post commit review as a rule, thought people is invited to keep
>   an eye on what other developers are doing and try to be helpful.
> - who reviews what... stingy one.
>   I'd say let's nominate module maintainers, but make sure we have at
>   least two official maintainers per core module (if we get more,
>   even better) so that they can review each other.
>   The maintainer concept should be not as strong as in GeoTools imho,
>   it should be more of a reviewing responsibility than "this is my
>   module and I do whatever I please with it".
> - what makes for big enough patches? Ha :-)
>   I'd say every new feature is big enough, no matter how small (that is,
>   the quality of the patch makes it review worthy, not much its size)
>   For bug fixes hmmm there are small ones and bigger ones for sure.
>   Some may be 10 lines with a patch outside of main/ows/platform, I
>   would not feel like asking review for those (small enough to be
>   understandable by looking at the commit list I'd say).
>   Some require reworking a group of classes, or it's code that is
>   used in a lot of places (stuff in main/ows), a review would be
>   advisable. Especially in main/ows changes a look at the patch
>   from whoever maintains affected modules is advisable (but
>   not mandatory).
>
> One thing that worries me about reviews is developer getting
> stuck waiting for a review, be frustrated, move to something else.
> We have to avoid that at all costs imho.
> I would like to see the following:
> - when there is a need for a review it should become the
>   highest priority for the other developers. At least, saying
>   "I'll review this" should be something that pops up within
>   the day (having somone that declares he'll do the review should
>   happen quickly)
> - the review itself should be taken care of quickly. No more
>   than a week delay imho unless the patch is really huge.
> What I mean is that the review system should flow like clear
> water, if developers start feeling stuck like in quicksands
> we have a problem (a serious one).
>
> Another very important thing is that we should have guidelines
> on how a review should be approached. Nothing big, just
> a good read to avoid reviews becoming dogfights over minor
> points. For example this one seems helpful:
> http://www.developer.com/tech/article.php/3579756
>
> Finally the process needs to be filled in. How does one
> post a patch for review? How does he ask for review?
> Do we use a tool like crucible or just attach a patch to
> jira?
>
> Code quality points should be detailed better. Looking at the
> existing ones performance can be measured, looking for edge
> cases and proper error handling is something that can be done
> via a line by line review, consistency can be checked by looking
> at other classes in the GeoServer code base.
> Aestetics wise heh, I don't know what is to be expected.
> Respecting the code conventions is an easy aestetics point.
> Having a checklist of others would be nice (like the style
> guide in the documentation.
> Maybe we could add that the changed code should pass a findbugs
> examination?
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.

Re: [Geoserver-devel] Rest Routing Improvements

2009-09-11 Thread Justin Deoliveira 
Andrea Aime wrote:
> David Winslow ha scritto:
>> Hey all.  I was recently added to this ticket:
>> http://jira.codehaus.org/browse/GEOS-3436 regarding restlet route
>> handling.  I've attached a small patch to it that addresses the basic
>> issue, but it brings to mind some larger concerns I have about
>> GeoServer's Restlet route handling.  Basically, routes for restlets in
>> GeoServer are dynamically added based on instances of a custom
>> RESTMapping class in the Spring context (example from my scriptlet
>> extension since it's short):
>>
>>> class="org.geoserver.rest.RESTMapping">
>> 
>> 
>> 
>> /script
>> javascriptRestlet
>> 
>> 
>> /script/{script}
>> javascriptRestlet
>> 
>> 
>> 
>> 
>>
>> This obscures some of the extra facilities provided by Restlet; there
>> are some settings regarding match "scoring" etc that are made globally
>> in the code that consumes this extension point.  The ticket addresses
>> one such decision; that all templates should use the default "starts
>> with" matching mode.  Since the index Restlet is routed to the empty
>> string, every request matches it, if nothing else.  My patch switches
>> this to "entire string" matching, which I think is probably appropriate
>> for this situation (this matching mode makes it less likely that
>> extensions will "steal" paths from each other.)
> 
> Sounds good
> 
>> However, Restlet also provides "types" for the variables in templates,
>> which we have thus far ignored, meaning all variables in templates are
>> using the default type, URI_SEGMENT.  However, there are further
>> restrictions that might be useful (digit sequences for example) and
>> relaxations that definitely would be handy, especially in light of
>> requiring full matches.  We would require this to, for example, provide
>> a service that exposes XML documents as arbitrary-depth hierarchies.
>>
>> This requires calling mutator function on the Route object created when
>> Router.attach is called.  The function takes a map
>> from name to variable specification, so we'd need to either set up an
>> encoding for these in spring, or expose an extension point allowing
>> routings to customize the Routes they generate.
> 
> Ok, I'm officially lost :-)
> Where can I read more about this topic?
> 
>> Going the all-spring route, I guess we could come up with some way of
>> annotating variables in routes with type info (like
>> "/path/{var?uri-segment}" or something. But this would be less
>> extensible and more of a pain to maintain, so I'm not going to explore
>> it in depth.
>>
>> I guess more explicit XML would look like: 
>>
>> > class="org.geoserver.rest.RESTMapping">
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> script
>> 
>> 9
>> 
>> 
>> 
>> 
>> 
>> 
> 
> I'm wondering if we can get to a compromise here that does not
> force us to use heavy syntax in all cases.
> Something like {script} is assumed to be a plain string without "/"
> inside of it if nothing else is stated.
> And then have the map just to declare what is the expected type.
> Or even just:
> 
> class="org.geoserver.rest.RESTMapping">
>   
>   
>   
>   /script
>   javascriptRestlet
>   
>   
>   /script/{script}
>   javascriptRestlet
>   
>   
>   
>   
>   
>  
> script
> 
> numeric
>   
>   
>   
> 
> 
>> We might want to wrap Variable so we can do a bit of magic letting us
>> use the name of the type instead of its numeric value, but you get the
>> idea.  This also exposes other features of Variable like default values.
> 
> Or alternatively:
> 
> class="org.geoserver.rest.RESTMapping">
>   
>   
>  ...
>   
>   
>   
>   
>  
>  numeric
>  0
>  
>  
>   
>   
>   
> 
> A pay as you go model. I think in the majority of cases our variables
> are non uri portion strings and they default to null?
> For this case I would prefer not to have to specify anything (would
> also make for backwards compatible approach, as we just add an
> optional property to the mix)

This is more along the lines of what I had in mind as well when I heard 
the initial pitch yesterda

Re: [Geoserver-devel] Some ideas for a catalog listener interface

2009-09-11 Thread Andrea Aime 
Justin Deoliveira ha scritto:
> Very cool idea. That could lead to some very interesting extensions 
> indeed. Since we already have a CatalogListener interface I would 
> probably recommend a different name. Something like 
> "ResourceAccessListener" maybe makes more sense?

Sure thing

Cheers
Andrea


-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Rest Routing Improvements

2009-09-11 Thread Andrea Aime 
David Winslow ha scritto:
> Hey all.  I was recently added to this ticket:
> http://jira.codehaus.org/browse/GEOS-3436 regarding restlet route
> handling.  I've attached a small patch to it that addresses the basic
> issue, but it brings to mind some larger concerns I have about
> GeoServer's Restlet route handling.  Basically, routes for restlets in
> GeoServer are dynamically added based on instances of a custom
> RESTMapping class in the Spring context (example from my scriptlet
> extension since it's short):
> 
> class="org.geoserver.rest.RESTMapping">
> 
> 
> 
> /script
> javascriptRestlet
> 
> 
> /script/{script}
> javascriptRestlet
> 
> 
> 
> 
> 
> This obscures some of the extra facilities provided by Restlet; there
> are some settings regarding match "scoring" etc that are made globally
> in the code that consumes this extension point.  The ticket addresses
> one such decision; that all templates should use the default "starts
> with" matching mode.  Since the index Restlet is routed to the empty
> string, every request matches it, if nothing else.  My patch switches
> this to "entire string" matching, which I think is probably appropriate
> for this situation (this matching mode makes it less likely that
> extensions will "steal" paths from each other.)

Sounds good

> However, Restlet also provides "types" for the variables in templates,
> which we have thus far ignored, meaning all variables in templates are
> using the default type, URI_SEGMENT.  However, there are further
> restrictions that might be useful (digit sequences for example) and
> relaxations that definitely would be handy, especially in light of
> requiring full matches.  We would require this to, for example, provide
> a service that exposes XML documents as arbitrary-depth hierarchies.
> 
> This requires calling mutator function on the Route object created when
> Router.attach is called.  The function takes a map
> from name to variable specification, so we'd need to either set up an
> encoding for these in spring, or expose an extension point allowing
> routings to customize the Routes they generate.

Ok, I'm officially lost :-)
Where can I read more about this topic?

> Going the all-spring route, I guess we could come up with some way of
> annotating variables in routes with type info (like
> "/path/{var?uri-segment}" or something. But this would be less
> extensible and more of a pain to maintain, so I'm not going to explore
> it in depth.
> 
> I guess more explicit XML would look like: 
> 
>  class="org.geoserver.rest.RESTMapping">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> script
> 
> 9
> 
> 
> 
> 
> 
> 

I'm wondering if we can get to a compromise here that does not
force us to use heavy syntax in all cases.
Something like {script} is assumed to be a plain string without "/"
inside of it if nothing else is stated.
And then have the map just to declare what is the expected type.
Or even just:

 
  
  
  
  /script
  javascriptRestlet
  
  
  /script/{script}
  javascriptRestlet
  
  
  
  
  
 
script

numeric
  
  
  


> We might want to wrap Variable so we can do a bit of magic letting us
> use the name of the type instead of its numeric value, but you get the
> idea.  This also exposes other features of Variable like default values.

Or alternatively:

 
  
  
 ...
  
  
  
  
 
 numeric
 0
 
 
  
  
  

A pay as you go model. I think in the majority of cases our variables
are non uri portion strings and they default to null?
For this case I would prefer not to have to specify anything (would
also make for backwards compatible approach, as we just add an
optional property to the mix)

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Repo

Re: [Geoserver-devel] review practices

2009-09-11 Thread Andrea Aime 
Andrea Aime ha scritto:

> Another very important thing is that we should have guidelines
> on how a review should be approached. Nothing big, just
> a good read to avoid reviews becoming dogfights over minor
> points. For example this one seems helpful:
> http://www.developer.com/tech/article.php/3579756

Btw, if we make a review checklist I would include these kind
of suggestions in it. This way when one goes over the various
points to be checked is also reminded on how to make a good
review.

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] web-sercurity module maintainer

2009-09-11 Thread Francesco Izzi 
Thanks Andrea,
I am honored to be maintainer of this module.

2009/9/11 Andrea Aime 

> Francesco Izzi ha scritto:
>
>> Hello list,
>> I'm working on the community module (web-security), and at this moment you
>> can configure all Geoserver security through user interface.
>>
>> I propose as the maintainer of this module.
>>
>
> Sure. I've left the module hanging for a while and I know you
> have sizeable patches to land on it. Go ahead :)
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>



-- 
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050  Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax:  +39 0971 427271
mob:+39 3402640314
mail: francesco.i...@geosdi.org
skype:  neofx8080

web: http://www.geosdi.org
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] web-sercurity module maintainer

2009-09-11 Thread Andrea Aime 
Francesco Izzi ha scritto:
> Hello list,
> I'm working on the community module (web-security), and at this moment 
> you can configure all Geoserver security through user interface.
> 
> I propose as the maintainer of this module.

Sure. I've left the module hanging for a while and I know you
have sizeable patches to land on it. Go ahead :)

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] review practices

2009-09-11 Thread Andrea Aime 
Justin Deoliveira ha scritto:
> Hi all,
> 
> Lately there has been a lot of talk around review practices. And in 
> general review is something that has becoming more frequent (which I 
> think is a great thing).

I guess one background question that we need to agree upon is:
do we want to raise the code quality and is software reviews the
way to get there?
I'm +1 on this, but given reviews take work, we need the commitment
of everybody else too.

> However, without an official policy in place review has been ambiguous, 
> with some people wondering when they need a review, etc...
> 
> So in an effort to rectify this I would like to come up with a code 
> review policy in GeoServer. I have put together a wiki page to foster 
> discussion:
> 
> http://geoserver.org/display/GEOS/Review+Practices
> 
> It needs to be expanded in a couple of places. After everyone weighs in 
> we can put together the official GSIP and update the developer guide.

Some opinions:
- I would say, let's just mandate pre-commit review on the bigger stuff.
   No post commit review as a rule, thought people is invited to keep
   an eye on what other developers are doing and try to be helpful.
- who reviews what... stingy one.
   I'd say let's nominate module maintainers, but make sure we have at
   least two official maintainers per core module (if we get more,
   even better) so that they can review each other.
   The maintainer concept should be not as strong as in GeoTools imho,
   it should be more of a reviewing responsibility than "this is my
   module and I do whatever I please with it".
- what makes for big enough patches? Ha :-)
   I'd say every new feature is big enough, no matter how small (that is,
   the quality of the patch makes it review worthy, not much its size)
   For bug fixes hmmm there are small ones and bigger ones for sure.
   Some may be 10 lines with a patch outside of main/ows/platform, I
   would not feel like asking review for those (small enough to be
   understandable by looking at the commit list I'd say).
   Some require reworking a group of classes, or it's code that is
   used in a lot of places (stuff in main/ows), a review would be
   advisable. Especially in main/ows changes a look at the patch
   from whoever maintains affected modules is advisable (but
   not mandatory).

One thing that worries me about reviews is developer getting
stuck waiting for a review, be frustrated, move to something else.
We have to avoid that at all costs imho.
I would like to see the following:
- when there is a need for a review it should become the
   highest priority for the other developers. At least, saying
   "I'll review this" should be something that pops up within
   the day (having somone that declares he'll do the review should
   happen quickly)
- the review itself should be taken care of quickly. No more
   than a week delay imho unless the patch is really huge.
What I mean is that the review system should flow like clear
water, if developers start feeling stuck like in quicksands
we have a problem (a serious one).

Another very important thing is that we should have guidelines
on how a review should be approached. Nothing big, just
a good read to avoid reviews becoming dogfights over minor
points. For example this one seems helpful:
http://www.developer.com/tech/article.php/3579756

Finally the process needs to be filled in. How does one
post a patch for review? How does he ask for review?
Do we use a tool like crucible or just attach a patch to
jira?

Code quality points should be detailed better. Looking at the
existing ones performance can be measured, looking for edge
cases and proper error handling is something that can be done
via a line by line review, consistency can be checked by looking
at other classes in the GeoServer code base.
Aestetics wise heh, I don't know what is to be expected.
Respecting the code conventions is an easy aestetics point.
Having a checklist of others would be nice (like the style
guide in the documentation.
Maybe we could add that the changed code should pass a findbugs
examination?

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] web-sercurity module maintainer

2009-09-11 Thread Francesco Izzi 
Hello list,
I'm working on the community module (web-security), and at this moment you
can configure all Geoserver security through user interface.

I propose as the maintainer of this module.

Cheers,

-- 
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050  Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax:  +39 0971 427271
mob:+39 3402640314
mail: francesco.i...@geosdi.org
skype:  neofx8080

web: http://www.geosdi.org
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] live dvd geoserver script for review

2009-09-11 Thread Jody Garnett 

This is mostly a summary of an IRC chat with Cameron and Andra


The live dvd for the foss4g conference is shaping up[1] - but the  
project has not heard anything from geoserver-devel.


There *is* a script for geoserver from 2008 - but it does not make the  
cut this year it requires a manual install:

- https://svn.osgeo.org/osgeo/livedvd/gisvm/trunk/bin/install_geoserver.sh

Andrea went over the above script on IRC (thanks) and mentioned a few  
things wrong:

- it uses the distributions tomcat[2]
- manual install step rather then copying into webapps
- we were worried about the version of Java -  it is sun java 6 but we  
are not sure what version


So we need a replacement...
- Deegree[3] is installing their own tomcat (in order to avoid the  
distribution one); so perhaps we can just use our jetty?
- Looks like there are some example demo layers that everyone is  
supposed to have in common


We are supposed to respect the following guidelines 1) be kind to ram,  
2) don't use too much disk space (I am sure the default geoserver will  
be fine) 3) desktop short cut to start / stop would be a bonus.


I think the idea is to download an image from http://download.osgeo.org/livedvd/ 
 and then try out a script. Additional information http://wiki.osgeo.org/wiki/Live_GIS_Disc


Cheers,
Jody Garnett

[1] 
http://cameronshorter.blogspot.com/2009/08/easy-steps-to-get-your-project-on.html
[2] https://svn.osgeo.org/osgeo/livedvd/gisvm/trunk/bin/install_tomcat6.sh
[3] https://svn.osgeo.org/osgeo/livedvd/gisvm/trunk/bin/install_deegree.sh--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel