http://permalink.gmane.org/gmane.comp.gis.geoserver.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21685 <pre>See &lt;http://hudson.opengeo.org/hudson/job/geoserver-master-nightly/1517/&gt; ------------------------------------------ [...truncated 2854 lines...] [INFO] Excluding net.sf.json-lib:json-lib:jar:jdk15:2.2.3 from the shaded jar. [INFO] Excluding commons-beanutils:commons-beanutils:jar:1.7.0 from the shaded jar. [INFO] Excluding net.sf.ezmorph:ezmorph:jar:1.0.6 from the shaded jar. [INFO] Excluding commons-digester:commons-digester:jar:1.7 from the shaded jar. [INFO] Excluding commons-fileupload:commons-fileupload:jar:1.2.1 from the shaded jar. [INFO] Excluding commons-validator:commons-validator:jar:1.1.4 from the shaded jar. [INFO] Excluding org.freemarker:freemarker:jar:2.3.18 from the shaded jar. [INFO] Excluding oro:oro:jar:2.0.8 from the shaded jar. [INFO] Excluding org.geotools:gt-cql:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-validation:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-data:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:g</pre> Hudson 2013-06-20T03:57:39 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21684 <pre>See &lt;http://hudson.opengeo.org/hudson/job/cite-wfs-1.1-2.3.x/141/&gt; -- This message is automatically generated by Hudson. For more information on Hudson, see: http://hudson-ci.org/ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev </pre> Hudson 2013-06-20T01:04:30 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21683 <pre>See &lt;http://hudson.opengeo.org/hudson/job/cite-wfs-1.1-2.3.x/140/&gt; ------------------------------------------ [...truncated 4166 lines...] [exec] Assertion: Run test group for cleaning up (deleting) the features inserted by the Transactions. [exec] Testing wfs:delete-test-data (wfs-1.1.0/d41e34700_1/d41e760_1/d41e31404_1/d41e26192_1/d41e24831_1)... [exec] Assertion: Deletes the test data used in transactions during the test run. [exec] Testing wfs:delete-feature (wfs-1.1.0/d41e34700_1/d41e760_1/d41e31404_1/d41e26192_1/d41e24831_1/d41e24858_1)... [exec] Assertion: [exec] Deletes a feature by typename and gml:name. [exec] [exec] Test wfs:delete-feature Passed [exec] Testing wfs:delete-feature (wfs-1.1.0/d41e34700_1/d41e760_1/d41e31404_1/d41e26192_1/d41e24831_1/d41e24867_1)... [exec] </pre> Hudson 2013-06-20T00:00:30 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21682 <pre> Simple, you don't need to. Jus call Dispatcher.REQUEST.get() and you'll get the Request object for the current thread. That's the nature of the thread locals: http://docs.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html Cheers Andrea </pre> Andrea Aime 2013-06-19T20:21:29 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21681 <pre>I'm trying to figure out how to get a hold of the url in my datastore java code to parse the parameter in the url. I've read the thread "accessing URL Parameters - msg#00434" suggesting: 1. "* If you add &amp;viewparams=p1:v1;p2:v2;.... into your request the* * datastore will receive a data access request with a Query containing, among its Hints at the Hints.VIRTUAL_TABLE_PARAMETERS key, **a hash map with the p1, v1, p2, v2 pairs."* I did not try exactly passing the parameter as "&amp;viewparams:p1:v1.." as suggested, in debug mode, I saw Hints.Table, but it did not have any data. 2. The other suggestion "*If you need something more generic and are willing to marry the store* * 1-1 to GeoServer you can also use the org.geoserver.ows.Dispatcher.REQUEST thread local, that one will contain the request and the various stages of its parsing, including the raw * *kvp, the parsed kvp, the parsed request object and so on.* " This is exactly what I want to try, but I can't figure out how to get a hold of the thread. Than</pre> n t 2013-06-19T18:10:35 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21680 <pre>2013/6/14 Justin Deoliveira &lt;jdeolive-uiWweP8TxstAfugRpC6u6w&lt; at &gt;public.gmane.org&gt; Hi Justin, I had a look at ResolvingProxy, but the problem seems to be that the Proxy created by it is not useful to prevent catalog load from failing if nested layergroups are present. I would be very glad if you, or someone else wishing to help, can have a look at my current fix for the issue before making the pull request. You can find it here: https://github.com/mbarto/geoserver/commit/197780165b83efe7202a1d4ac462036c59495ccd As I was saying in the last email, I built an explicit Proxy (LateBinding stuff), implementing some of the LayerGroupInfo interface methods to avoid failures during Catalog loading. I don't know if the ResolvingProxy could be adapted to accomplish the same task. I tried in several ways, but didn't find how to make it work in this situation. The late binding phase executes at the end of the loading when all the Catalog objects should be available. Maybe when doing late binding, some of the checks done </pre> Mauro Bartolomeoli 2013-06-19T17:25:27 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21679 <pre>------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev_______________________________________________ Geoserver-devel mailing list Geoserver-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/geoserver-devel </pre> Andrea Aime (JIRA 2013-06-19T16:28:03 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21678 <pre> Thank you Chris :-) Cheers Andrea </pre> Andrea Aime 2013-06-19T15:26:26 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21677 <pre>Hi Justin, how are things going importer wise? If OpenGeo thinks it would be hard to contribute the Suite importer that's a pity, but not the end of the world, we're still on board with contributing our less evolved version to GeoServer if needs be. Cheers Andrea </pre> Andrea Aime 2013-06-19T13:38:14 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21676 <pre>------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev_______________________________________________ Geoserver-devel mailing list Geoserver-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/geoserver-devel </pre> Renato Primavera (JIRA 2013-06-19T13:38:03 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21675 <pre>I'm trying to figure out how to get a hold of the url in my datastore java code to parse the parameter in the url. I've read the thread "accessing URL Parameters - msg#00434" suggesting: 1. "* If you add &amp;viewparams=p1:v1;p2:v2;.... into your request the* * datastore will receive a data access request with a Query containing, among its Hints at the Hints.VIRTUAL_TABLE_PARAMETERS key, **a hash map with the p1, v1, p2, v2 pairs."* I did not try exactly passing the parameter as "&amp;viewparams:p1:v1.." as suggested, in debug mode, I saw Hints.Table, but it did not have any data. 2. The other suggestion "*If you need something more generic and are willing to marry the store* * 1-1 to GeoServer you can also use the org.geoserver.ows.Dispatcher.REQUEST thread local, that one will contain the request and the various stages of its parsing, including the raw * *kvp, the parsed kvp, the parsed request object and so on.* " This is exactly what I want to try, but I can't figure out how to get a hold of the thread. Than</pre> m l 2013-06-19T13:35:54 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21674 <pre>------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev_______________________________________________ Geoserver-devel mailing list Geoserver-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org https://lists.sourceforge.net/lists/listinfo/geoserver-devel </pre> Tim Astle (JIRA 2013-06-19T13:14:03 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21673 <pre>On Tue, Jun 18, 2013 at 7:46 PM, Andrea Aime &lt;andrea.aime-tfsaCHwD3UxEjNxWwoHljQ&lt; at &gt;public.gmane.org&gt;wrote: Looked into the GeoSearch module and found out it's all rest config and user interface, there are no kml generation bits in there. So all that's needed, once the new kml2 module graduates, is to move the geosearch specific kml generation bits (3 classes, one abstract class and two placemark decorators) to the geosearch module so that they do activate only when the geosearch module is added to the install GeoServer Cheers Andrea </pre> Andrea Aime 2013-06-19T10:41:22 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21672 <pre>On Tue, Jun 18, 2013 at 11:20 AM, Andrea Aime &lt;andrea.aime-tfsaCHwD3UxEjNxWwoHljQ&lt; at &gt;public.gmane.org&gt;wrote: I had another look at the whole matter and believe this can be solved without having to modify GWC at all. GeoServer has two methods to load and save the JDBC configuration (used by the GUI), so I just need to tap into those and encrypt the password before it gets saved, and decrypt it on the way back, before GWC can start using it. I cannot know if the password is encrypted or not just by searching for the well known prefixes, but I can just test with each GeoServer password encoder if the value is something it can handle, and if none is found, assume the password is still plaintext. Might have some little glitch for some unlucky cases where the plaintext password is matched by some password encoder, but that should be very unlikely, and the functionality is only a few months old, and only useful in clustered environments, so very few people are probably already using it. Plus it has a simple fix, ju</pre> Andrea Aime 2013-06-19T09:52:06 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21671 <pre>Hi everybody, I created a pull request ( https://github.com/geoserver/geoserver/pull/253) for this that used a language parameter in the request to choose a Locale for rule labels. Thanks Mauro Bartolomeoli 2013/6/14 Andrea Aime &lt;andrea.aime-tfsaCHwD3UxEjNxWwoHljQ&lt; at &gt;public.gmane.org&gt; </pre> Mauro Bartolomeoli 2013-06-19T07:58:01 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21670 <pre>See &lt;http://hudson.opengeo.org/hudson/job/geoserver-master-nightly/1516/&gt; ------------------------------------------ [...truncated 2854 lines...] [INFO] Excluding net.sf.json-lib:json-lib:jar:jdk15:2.2.3 from the shaded jar. [INFO] Excluding commons-beanutils:commons-beanutils:jar:1.7.0 from the shaded jar. [INFO] Excluding net.sf.ezmorph:ezmorph:jar:1.0.6 from the shaded jar. [INFO] Excluding commons-digester:commons-digester:jar:1.7 from the shaded jar. [INFO] Excluding commons-fileupload:commons-fileupload:jar:1.2.1 from the shaded jar. [INFO] Excluding commons-validator:commons-validator:jar:1.1.4 from the shaded jar. [INFO] Excluding org.freemarker:freemarker:jar:2.3.18 from the shaded jar. [INFO] Excluding oro:oro:jar:2.0.8 from the shaded jar. [INFO] Excluding org.geotools:gt-cql:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-validation:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-data:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:g</pre> Hudson 2013-06-19T04:07:46 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21669 <pre>I think "snapping" to the closest pixel location is great - and should be the default (we can still perform anti-aliasing in this case, but by aligning to the pixel grid we should have a noticeable improvement in quality). I was also wondering if there is any advantage in quality for performing the same "snap" for text rendering? Probably only for fonts that are defined with pixels in mind. </pre> Jody Garnett 2013-06-19T03:01:28 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21668 <pre>Hi, the KML2 module is almost ready as a KML module replacement, so I wanted to give people an introduction to its features and design, given that the next steps are going to be mostly bug fixes (unless I receive negative feedback on some design elements of course). As already reported in a previous thread (March 1st) the module builds KML documents as object model trees based on the JAK library ( https://code.google.com/p/javaapiforkml/) and uses the JDK own JAXB library to then serialize the resulting tree. Tests have been made to make sure JAXB is not affecting WFS CITE tests. There are three KML object model builders in the codebase, two of them building a small KML made mostly of links, and one that is streaming, based on lists that are evaluated as they are traversed: https://github.com/geoserver/geoserver/tree/master/src/community/kml2/src/main/java/org/geoserver/kml/builder For example, the simple network link builder just builds a kml with a networklink for each layer: https://github.com/geoserve</pre> Andrea Aime 2013-06-18T17:46:02 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21667 <pre> We should thank the Warwickshire County Council ( http://www.warwickshire.gov.uk) for sponsoring fixes for GEOS-5536 and GEOS-4760 Cheers Andrea </pre> Andrea Aime 2013-06-18T09:25:38 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21666 <pre>On Sat, Jun 15, 2013 at 5:06 PM, Christian Mueller &lt; christian.mueller-oYvOZWUA52Cizx07SSSpcQ&lt; at &gt;public.gmane.org&gt; wrote: This one troubles me. As said, standalone GWC users are forced into editing the configuration files by hand, having to force this kind of change on them is going to be nasty, and would make little sense too since I don't see any standalone GWC user encrypting passwords anyways. For the embedded GWC, the only place where a password can reside that has a GUI editor is the disk quota database, so that's the only password that might have to be rewritten. This recodeAll method you're citing, does it have a GeoServer equivalent? I guess it's done on startup when figuring out the data dir has the old security system, right? In the embedded GWC case I'd have no such information, the only way to figure out passwords are not encoded is when reading the disk quota configuration, and finding there is no prefix, so I guess that's where the eventual re-coding should happen. I should probably add a "en</pre> Andrea Aime 2013-06-18T09:20:33 http://permalink.gmane.org/gmane.comp.gis.geoserver.devel/21665 <pre>See &lt;http://hudson.opengeo.org/hudson/job/geoserver-master-nightly/1515/&gt; ------------------------------------------ [...truncated 2921 lines...] [INFO] Excluding commons-fileupload:commons-fileupload:jar:1.2.1 from the shaded jar. [INFO] Excluding commons-validator:commons-validator:jar:1.1.4 from the shaded jar. [INFO] Excluding org.freemarker:freemarker:jar:2.3.18 from the shaded jar. [INFO] Excluding oro:oro:jar:2.0.8 from the shaded jar. [INFO] Excluding org.geotools:gt-cql:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-validation:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-data:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-jdbc:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-property:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding org.geotools:gt-epsg-hsql:jar:10-SNAPSHOT from the shaded jar. [INFO] Excluding hsqldb:hsqldb:jar:1.8.0.7 from the shaded jar. [INFO] Excluding org.geotools:gt-wms:jar:10-SNA</pre> Hudson 2013-06-18T03:56:15 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gis.geoserver.devel