Nabble - GeoServer - Dev

DGN support in GeoServer

2009-12-18T10:22:59Z

Hello All,

Can anyone direct me to how DGN files can be supported in GeoServer (adding them as data store like a shape file)? Does GeoServer support all the vector formats of OGR?

Any help in this regard would be quite helpful for me.

Thanks in advance,
Bala

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jira] Created: (GEOS-3733) Handling Temporal Domain Subset on WCS 1.1

2009-12-18T09:04:55Z

Handling Temporal Domain Subset on WCS 1.1
------------------------------------------

Key: GEOS-3733
URL: http://jira.codehaus.org/browse/GEOS-3733
Project: GeoServer
Issue Type: Improvement
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani
Fix For: 2.1.x

At this time the TimeSequence parsers for WCS 1.1 have not been implemented.

This improvement allows WCS 1.1.x to parse and handle time domain subset reuquests.

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hudson build is back to normal: geoserver-trunk #2244

2009-12-18T08:46:40Z

See <http://hudson.opengeo.org/hudson/job/geoserver-trunk/2244/changes>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jira] Created: (GEOS-3732) WCS 1.0 needs a specific Bbox parser

2009-12-18T08:21:56Z

WCS 1.0 needs a specific Bbox parser
------------------------------------

Key: GEOS-3732
URL: http://jira.codehaus.org/browse/GEOS-3732
Project: GeoServer
Issue Type: Bug
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani
Fix For: 2.1.x

The general BBOX kvp parser on GeoServer maps the coordinates into a ReferencedEnvelope object which allows only 2D spatial reference systems. The WCS 1.0 allows instead also 3D bboxes in order to let users specify also the z dimension.

For this reason we should grab the WCS 1.0 bbox as a GeneralEnvelope and not as a ReferencedEnvelope.

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jira] Created: (GEOS-3731) KvpUtils ignores specific Service KVPParsers if present

2009-12-18T08:15:55Z

KvpUtils ignores specific Service KVPParsers if present
-------------------------------------------------------

Key: GEOS-3731
URL: http://jira.codehaus.org/browse/GEOS-3731
Project: GeoServer
Issue Type: Bug
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani
Fix For: 2.1.x

If a service defines a KVP parser for a Key clashing with already defined general KVP parsers, the KVPUtils randomly chooses the KVP parser for that key, ignoring specific service and version parameters.

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Build failed in Hudson: geoserver-trunk #2243

2009-12-18T04:39:03Z

See <http://hudson.opengeo.org/hudson/job/geoserver-trunk/2243/changes>

Changes:

[aaime] GUI was showing namespace label as the toString() of ResoureModel instead of showing the actual label

------------------------------------------
[...truncated 19873 lines...]
PARAMETER["central_meridian", -93.0],
PARAMETER["latitude_of_origin", 0.0],
PARAMETER["scale_factor", 0.9996],
PARAMETER["false_easting", 500000.0],
PARAMETER["false_northing", 0.0],
UNIT["m", 1.0],
AXIS["Easting", EAST],
AXIS["Northing", NORTH],
AUTHORITY["EPSG","32615"]]-->
<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Polygons" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:Ponds</Name>
<Title>Ponds</Title>
<Abstract>abstract about Ponds</Abstract>
<KeywordList>
<Keyword>Ponds</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Ponds</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Ponds" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>sf:PrimitiveGeoFeature</Name>
<Title>PrimitiveGeoFeature</Title>
<Abstract>abstract about PrimitiveGeoFeature</Abstract>
<KeywordList>
<Keyword>PrimitiveGeoFeature</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=PrimitiveGeoFeature" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:RoadSegments</Name>
<Title>RoadSegments</Title>
<Abstract>abstract about RoadSegments</Abstract>
<KeywordList>
<Keyword>RoadSegments</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>RoadSegments</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=RoadSegments" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cdf:Seven</Name>
<Title>Seven</Title>
<Abstract>abstract about Seven</Abstract>
<KeywordList>
<Keyword>Seven</Keyword>
</KeywordList>
<SRS>EPSG:32615</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Seven" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:Streams</Name>
<Title>Streams</Title>
<Abstract>abstract about Streams</Abstract>
<KeywordList>
<Keyword>Streams</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Streams</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Streams" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cdf:Updates</Name>
<Title>Updates</Title>
<Abstract>abstract about Updates</Abstract>
<KeywordList>
<Keyword>Updates</Keyword>
</KeywordList>
<SRS>EPSG:32615</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Updates" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities>
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.636 sec
Running org.vfny.geoserver.wms.requests.DescribeLayerKvpRequestReaderTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.vfny.geoserver.wms.responses.featureinfo.FeatureTemplateTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.454 sec

Results :

Failed tests:
testRemoteOWSGet(org.vfny.geoserver.wms.responses.map.png.GetMapTest)

Tests run: 167, Failures: 1, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.

Please refer to <http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/wms/target/surefire-reports> for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 minutes 33 seconds
[INFO] Finished at: Fri Dec 18 07:39:02 EST 2009
[INFO] Final Memory: 40M/115M
[INFO] ------------------------------------------------------------------------

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geotools-devel] SUN specific import statements

2009-12-17T23:52:43Z

Christian Müller ha scritto:
> Do we have a possibility to check for SUN specific imports before we commit
> to svn.

Christian, imho committing is already hard enough, we have to make a
built and when feasible add tests...

Once the build bots get to a stable state we can make them send mails
to the ml, that should inform us of such errors. If things can be setup
so that there is an IBM build every day we should have a decently
quick feedback.

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

SUN specific import statements

2009-12-17T23:47:04Z

Do we have a possibility to check for SUN specific imports before we commit
to svn.

One such statement breaks at least 4 builds on the build server (the IBM
builds, I did not check openJDK).

Happened today in JDBCDataStoreFactory, I fixed this issue.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: Loud warning: code freeze starting today :-)

2009-12-17T21:43:08Z

It might be more straightforward to add a GeoTools Jira filter to the
roadmap, and consider anything the is fix-version in the corresponding
GeoTools release to block the GeoServer release.

On 18/12/09 13:37, Mark Leslie wrote:

> From what I recall there's precedent to filing a GeoServer issue that
> depends on the GeoTools issue for traceability.
>
> Ben Caradoc-Davies wrote:
>> Thanks, Mark.
>>
>> should I indicate a blocking GeoTools issue in the GeoServer Roadmap,
>> and if so, how should I do it? The Jira filter only reports GeoServer
>> issues.
>>
>> Should I file a GeoServer fix-version 2.0.1 issue to shadow the GT
>> issue? Or is this just too much duplication?
>>
>> Note: I'll be leaving in two and a half hours. Back in a month. :-)
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 18/12/09 13:20, Mark Leslie wrote:
>>> It looks like we've managed to get from two blocking issues last week
>>> down to two new blocking issues this week:
>>>
>>> http://jira.codehaus.org/browse/GEOS-3729
>>> http://jira.codehaus.org/browse/GEOS-3702
>>>
>>> And Ben has flagged another in GeoTools, which I believe was tagged
>>> earlier today:
>>>
>>> http://jira.codehaus.org/browse/GEOT-2897
>>>
>>>
>>> Andrea Aime wrote:
>>>> Hi,
>>>> since we're going to release next week it should
>>>> be freeze time.
>>>>
>>>> Which does not mean no commits at all btw, it means
>>>> no commits unless you're fixing a critical bug
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: Loud warning: code freeze starting today :-)

2009-12-17T21:37:58Z

From what I recall there's precedent to filing a GeoServer issue that
depends on the GeoTools issue for traceability.

Ben Caradoc-Davies wrote:

> Thanks, Mark.
>
> should I indicate a blocking GeoTools issue in the GeoServer Roadmap,
> and if so, how should I do it? The Jira filter only reports GeoServer
> issues.
>
> Should I file a GeoServer fix-version 2.0.1 issue to shadow the GT
> issue? Or is this just too much duplication?
>
> Note: I'll be leaving in two and a half hours. Back in a month. :-)
>
> Kind regards,
> Ben.
>
>
> On 18/12/09 13:20, Mark Leslie wrote:
>> It looks like we've managed to get from two blocking issues last week
>> down to two new blocking issues this week:
>>
>> http://jira.codehaus.org/browse/GEOS-3729
>> http://jira.codehaus.org/browse/GEOS-3702
>>
>> And Ben has flagged another in GeoTools, which I believe was tagged
>> earlier today:
>>
>> http://jira.codehaus.org/browse/GEOT-2897
>>
>>
>> Andrea Aime wrote:
>>> Hi,
>>> since we're going to release next week it should
>>> be freeze time.
>>>
>>> Which does not mean no commits at all btw, it means
>>> no commits unless you're fixing a critical bug
>>>
>>> Cheers
>>> Andrea
>>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@...
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: Loud warning: code freeze starting today :-)

2009-12-17T21:31:49Z

Thanks, Mark.

should I indicate a blocking GeoTools issue in the GeoServer Roadmap,
and if so, how should I do it? The Jira filter only reports GeoServer
issues.

Should I file a GeoServer fix-version 2.0.1 issue to shadow the GT
issue? Or is this just too much duplication?

Note: I'll be leaving in two and a half hours. Back in a month. :-)

Kind regards,
Ben.

On 18/12/09 13:20, Mark Leslie wrote:

> It looks like we've managed to get from two blocking issues last week
> down to two new blocking issues this week:
>
> http://jira.codehaus.org/browse/GEOS-3729
> http://jira.codehaus.org/browse/GEOS-3702
>
> And Ben has flagged another in GeoTools, which I believe was tagged
> earlier today:
>
> http://jira.codehaus.org/browse/GEOT-2897
>
>
> Andrea Aime wrote:
>> Hi,
>> since we're going to release next week it should
>> be freeze time.
>>
>> Which does not mean no commits at all btw, it means
>> no commits unless you're fixing a critical bug
>>
>> Cheers
>> Andrea
>>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

Re: Loud warning: code freeze starting today :-)

2009-12-17T21:20:28Z

It looks like we've managed to get from two blocking issues last week
down to two new blocking issues this week:

http://jira.codehaus.org/browse/GEOS-3729
http://jira.codehaus.org/browse/GEOS-3702

And Ben has flagged another in GeoTools, which I believe was tagged
earlier today:

http://jira.codehaus.org/browse/GEOT-2897

Andrea Aime wrote:

> Hi,
> since we're going to release next week it should
> be freeze time.
>
> Which does not mean no commits at all btw, it means
> no commits unless you're fixing a critical bug
>
> Cheers
> Andrea
>

[jira] Created: (GEOS-3730) line widths in styles are converted to whole numbers using KML output

2009-12-17T20:42:59Z

line widths in styles are converted to whole numbers using KML output
---------------------------------------------------------------------

Key: GEOS-3730
URL: http://jira.codehaus.org/browse/GEOS-3730
Project: GeoServer
Issue Type: Bug
Components: Google Earth KML Output
Affects Versions: 2.0.0
Reporter: Miles Jordan
Assignee: Andrea Aime

If you create a style that has a float as a width for a line, it is floored to an integer value when it is being requested as part of KML. If the width is < 1, Google Earth will not display the line at all, because the KML specifies that the line has a width of 0.

Take this SLD for example:
<?xml version="1.0" encoding="ISO-8859-1"?>
<StyledLayerDescriptor version="1.0.0"
xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd"
xmlns="http://www.opengis.net/sld"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NamedLayer>
<Name>Default Line</Name>
<UserStyle>
<Title>A boring default style</Title>
<FeatureTypeStyle>
<Rule>
<LineSymbolizer>
<Stroke>
<CssParameter name="stroke">#FF0000</CssParameter>
<CssParameter name="stroke-width">0.5</CssParameter>
</Stroke>
</LineSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>

Apply it to a layer, and check the KML output. The width of the line style will be 0, as opposed to 0.5.

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: datastore management on nightly build [Sec=Unclassified]

2009-12-17T20:13:33Z

I think I just reported the same bug. Actually found by Florence Tan
attempting to deploy a patched GeoServer trunk for NVCL; I think we
found the cause:
http://jira.codehaus.org/browse/GEOT-2897

Yes, this is a release blocker.

Thanks for reporting this one Miles. It is good to get confirmation that
we are not the only ones affected.

Kind regards,
Ben.

On 18/12/09 11:33, Miles Jordan wrote:

> Just a quick note as I know the next release is imminent...
>
> I'm just playing with the 17-dec nightly build and firstly my JNDI Oracle datastores failed to load from my existing configuration (I had to remove them and add them again) and secondly I can't seem to edit any datastores at all - nothing happens when the save button is pushed except if you are adding a new datastore.
>
> No biggie but wouldn't look so hot in a release. Should I file an issue on this?
>
> Cheers,
>
> Miles
>
>
> ___________________________________________________________________________
>
> Australian Antarctic Division - Commonwealth of Australia
> IMPORTANT: This transmission is intended for the addressee only. If you are not the
> intended recipient, you are notified that use or dissemination of this communication is
> strictly prohibited by Commonwealth law. If you have received this transmission in error,
> please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
> DELETE the message.
> Visit our web site at http://www.antarctica.gov.au/
> ___________________________________________________________________________
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

Oracle NG failure: GeoServer 2.0.1 release blocker

2009-12-17T20:01:51Z

I think we have a GeoServer 2.0.1 release blocker:

GEOT-2897: Oracle NG failure caused by Oracle NG OCI support
http://jira.codehaus.org/browse/GEOT-2897

This was found on GS trunk but, according to Jira (and Andrea's diligent
backporting) this likely affects 2.0.x.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: datastore management on nightly build [Sec=Unclassified] [Sec=Unclassified]

2009-12-17T19:36:47Z

Miles Jordan wrote:

> Just a quick note as I know the next release is imminent...
>
> I'm just playing with the 17-dec nightly build and firstly my JNDI
> Oracle datastores failed to load from my existing configuration (I had
> to remove them and add them again) and secondly I can't seem to edit
> any datastores at all - nothing happens when the save button is pushed
> except if you are adding a new datastore.
>
> No biggie but wouldn't look so hot in a release. Should I file an
> issue on this?

Also getting an exception when clicking on "Layers", from the OCI datastore (even though I don't have one set up):

java.lang.NoSuchFieldError: PK_METADATA_TABLE
org.geotools.data.oracle.OracleNGOCIDataStoreFactory.setupParameters(OracleNGOCIDataStoreFactory.java:85)
org.geotools.jdbc.JDBCDataStoreFactory.getParametersInfo(JDBCDataStoreFactory.java:210)
org.geotools.data.AbstractDataStoreFactory.canProcess(AbstractDataStoreFactory.java:115)
org.geotools.jdbc.JDBCDataStoreFactory.canProcess(JDBCDataStoreFactory.java:105)
org.vfny.geoserver.util.DataStoreUtils.aquireFactory(DataStoreUtils.java:139)
org.vfny.geoserver.util.DataStoreUtils.getDataAccess(DataStoreUtils.java:91)
org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:298)
org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:535)
org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureType(FeatureTypeInfoImpl.java:86)
sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:114)
$Proxy13.getFeatureType(Unknown Source)
org.geoserver.web.CatalogIconFactory.getSpecificLayerIcon(CatalogIconFactory.java:112)
org.geoserver.web.data.layer.LayerPage$1.getComponentForProperty(LayerPage.java:52)
org.geoserver.web.wicket.GeoServerTablePanel$1$1.populateItem(GeoServerTablePanel.java:134)
org.apache.wicket.markup.html.list.ListView.onPopulate(ListView.java:573)
org.apache.wicket.markup.repeater.AbstractRepeater.onBeforeRender(AbstractRepeater.java:127)
org.apache.wicket.Component.internalBeforeRender(Component.java:1009)

___________________________________________________________________________

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___________________________________________________________________________
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

datastore management on nightly build [Sec=Unclassified]

2009-12-17T19:33:42Z

Just a quick note as I know the next release is imminent...

I'm just playing with the 17-dec nightly build and firstly my JNDI Oracle datastores failed to load from my existing configuration (I had to remove them and add them again) and secondly I can't seem to edit any datastores at all - nothing happens when the save button is pushed except if you are adding a new datastore.

No biggie but wouldn't look so hot in a release. Should I file an issue on this?

Cheers,

Miles

___________________________________________________________________________

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___________________________________________________________________________
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T12:04:35Z

Cool, thanks for the clarification. And yeah I think you are right that
it is just too slippery of a slope when you start having overlapping
patterns like this.

David Winslow wrote:

> No, I agree with you that it would be awesome to avoid requiring
> modifications to web.xml for extensions (and putting in a bunch of dead
> mappings that only kick in when certain extensions are present.)
>
> But, I think we could be digging ourselves into a hole with freestyle
> mapping like what you are proposing. In particular, it gets hairy when
> there are wildcard expressions that overlap; in the example I brought up
> earlier there would be wildcards like:
>
> /*/wms
> /rest/*
>
> The point that I was trying to get at was that (I think) we should avoid
> having wildcards/placeholders at the same level as predetermined text
> values in the route hierarchy. As a more concrete example, right now
> 'default' is a magic workspace name in the REST API, so when you make a
> request to
> /rest/workspaces/foo you get the description for workspace foo, but when
> you request
> /rest/workspaces/default you get something a little different. (I
> forget whether it is the representation of the workspace that happens to
> be default, or a special document that links to the default workspace.)
>
> So we have to special-case 'default' there, and if an admin creates a
> workspace named "default" then he broke the REST API (or we have to add
> checks everywhere a workspace can be added/edited to avoid that). What
> I was trying to say is that we should try to avoid this sort of
> ambiguous path.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On 12/17/2009 01:45 PM, Justin Deoliveira wrote:
>> Sorry, not sure I 100% follow. So I think you are saying that like the
>> way it is today with a pre defined closed set of top level mappings?
>>
>> David Winslow wrote:
>>> On 12/17/2009 11:49 AM, Justin Deoliveira wrote:
>>>> No. Forget virtual services for the context of this problem :)
>>>> Apologies for confusing two issues. This problem is:
>>>>
>>>> a) to allow services to plug in under the root context without
>>>> modifying web.xml
>>>>
>>>> b) to allow for more complex mappings, ie /*/ows/** rather than just
>>>> /ows/*
>>>>
>>> I think the question of overlapping paths is a good one. If we allow
>>> administrators to bind stuff to arbitrary path prefixes, what happens
>>> when I have an experimental RESTful WMS service at /rest/wms/ and
>>> some user decides to create his map of all the rest stops in Kentucky
>>> at /rest/wms/ ? Either we have a situation where the user can create
>>> a configuration that silently replaces one service with another, or
>>> we have to provide some validation on service names that is aware of
>>> the path patterns and how they interact. Neither option seems very
>>> appealing to me.
>>>
>>> So, personally, I am in favor of keeping user-defined path segments
>>> separate from developer-defined ones. (ie, /some-specific-path/<name
>>> from config> and /some-specific-path/hard-coded-magic-id should very
>>> rarely be part of the same service.) Prefixes for different classes
>>> of service (ows, rest plugins, web pages) seem like a pretty
>>> manageable way to maintain that.
>>>
>>> Just my 2 cents.
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T11:50:39Z

No, I agree with you that it would be awesome to avoid requiring
modifications to web.xml for extensions (and putting in a bunch of dead
mappings that only kick in when certain extensions are present.)

But, I think we could be digging ourselves into a hole with freestyle
mapping like what you are proposing. In particular, it gets hairy when
there are wildcard expressions that overlap; in the example I brought up
earlier there would be wildcards like:

/*/wms
/rest/*

The point that I was trying to get at was that (I think) we should avoid
having wildcards/placeholders at the same level as predetermined text
values in the route hierarchy. As a more concrete example, right now
'default' is a magic workspace name in the REST API, so when you make a
request to
/rest/workspaces/foo you get the description for workspace foo, but when
you request
/rest/workspaces/default you get something a little different. (I
forget whether it is the representation of the workspace that happens to
be default, or a special document that links to the default workspace.)

So we have to special-case 'default' there, and if an admin creates a
workspace named "default" then he broke the REST API (or we have to add
checks everywhere a workspace can be added/edited to avoid that). What
I was trying to say is that we should try to avoid this sort of
ambiguous path.

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

On 12/17/2009 01:45 PM, Justin Deoliveira wrote:

> Sorry, not sure I 100% follow. So I think you are saying that like the
> way it is today with a pre defined closed set of top level mappings?
>
> David Winslow wrote:
>> On 12/17/2009 11:49 AM, Justin Deoliveira wrote:
>>> No. Forget virtual services for the context of this problem :)
>>> Apologies for confusing two issues. This problem is:
>>>
>>> a) to allow services to plug in under the root context without
>>> modifying web.xml
>>>
>>> b) to allow for more complex mappings, ie /*/ows/** rather than just
>>> /ows/*
>>>
>> I think the question of overlapping paths is a good one. If we allow
>> administrators to bind stuff to arbitrary path prefixes, what happens
>> when I have an experimental RESTful WMS service at /rest/wms/ and
>> some user decides to create his map of all the rest stops in Kentucky
>> at /rest/wms/ ? Either we have a situation where the user can create
>> a configuration that silently replaces one service with another, or
>> we have to provide some validation on service names that is aware of
>> the path patterns and how they interact. Neither option seems very
>> appealing to me.
>>
>> So, personally, I am in favor of keeping user-defined path segments
>> separate from developer-defined ones. (ie, /some-specific-path/<name
>> from config> and /some-specific-path/hard-coded-magic-id should very
>> rarely be part of the same service.) Prefixes for different classes
>> of service (ows, rest plugins, web pages) seem like a pretty
>> manageable way to maintain that.
>>
>> Just my 2 cents.
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>

Re: the servlet-mapping problem

2009-12-17T10:45:23Z

Sorry, not sure I 100% follow. So I think you are saying that like the
way it is today with a pre defined closed set of top level mappings?

David Winslow wrote:

> On 12/17/2009 11:49 AM, Justin Deoliveira wrote:
>> No. Forget virtual services for the context of this problem :) Apologies
>> for confusing two issues. This problem is:
>>
>> a) to allow services to plug in under the root context without modifying
>> web.xml
>>
>> b) to allow for more complex mappings, ie /*/ows/** rather than just /ows/*
>>
>>
> I think the question of overlapping paths is a good one. If we allow
> administrators to bind stuff to arbitrary path prefixes, what happens
> when I have an experimental RESTful WMS service at /rest/wms/ and some
> user decides to create his map of all the rest stops in Kentucky at
> /rest/wms/ ? Either we have a situation where the user can create a
> configuration that silently replaces one service with another, or we
> have to provide some validation on service names that is aware of the
> path patterns and how they interact. Neither option seems very
> appealing to me.
>
> So, personally, I am in favor of keeping user-defined path segments
> separate from developer-defined ones. (ie, /some-specific-path/<name
> from config> and /some-specific-path/hard-coded-magic-id should very
> rarely be part of the same service.) Prefixes for different classes of
> service (ows, rest plugins, web pages) seem like a pretty manageable way
> to maintain that.
>
> Just my 2 cents.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/

Hudson build is back to normal: geoserver-trunk #2238

2009-12-17T09:32:32Z

See <http://hudson.opengeo.org/hudson/job/geoserver-trunk/2238/>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T09:09:02Z

On 12/17/2009 11:49 AM, Justin Deoliveira wrote:

No. Forget virtual services for the context of this problem :) Apologies 
for confusing two issues. This problem is:

a) to allow services to plug in under the root context without modifying 
web.xml

b) to allow for more complex mappings, ie /*/ows/** rather than just /ows/*

I think the question of overlapping paths is a good one. If we allow administrators to bind stuff to arbitrary path prefixes, what happens when I have an experimental RESTful WMS service at /rest/wms/ and some user decides to create his map of all the rest stops in Kentucky at /rest/wms/ ? Either we have a situation where the user can create a configuration that silently replaces one service with another, or we have to provide some validation on service names that is aware of the path patterns and how they interact. Neither option seems very appealing to me.

So, personally, I am in favor of keeping user-defined path segments separate from developer-defined ones. (ie, /some-specific-path/<name from config> and /some-specific-path/hard-coded-magic-id should very rarely be part of the same service.) Prefixes for different classes of service (ows, rest plugins, web pages) seem like a pretty manageable way to maintain that.

Just my 2 cents.

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jira] Created: (GEOS-3729) Styled overwritten on data directory conversion when file ends with .xml

2009-12-17T08:54:55Z

Styled overwritten on data directory conversion when file ends with .xml
------------------------------------------------------------------------

Key: GEOS-3729
URL: http://jira.codehaus.org/browse/GEOS-3729
Project: GeoServer
Issue Type: Bug
Reporter: Justin Deoliveira
Assignee: Justin Deoliveira
Priority: Blocker
Fix For: 2.0.1

And the id matches the file name.

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T08:51:09Z

Gabriel Roldan wrote:
> The thing is, mapping /*/wfs/* might also mean trouble if any other
> resource has a "wfs" step?

This could be a potential problem yes. But since all the matching is
done with ant style patterns (which are quite flexible) we should be
able to get around any conflicts.

>
> Gabriel Roldan wrote:
>> So you're chasing for a general solution to avoid servlet mappings in
>> web.xml? I thought it was just about the virtual services being hard
>> to map as conceived because it would force the /* mapping to ows.
>>
>> So I meant you can map /ows/* to the dispatcher and from that on
>> introduce the virtual services
>>
>>> I am not quite sure I understand what you are getting at. I agree
>>> that the "wms", "wfs", and "wcs" mappings can be considered as
>>> aliases for "ows". But that seems sort of orthogonal to the problem.
>>> Even if we disallowed them we would still have the same problem just
>>> one level up not being able to add services, reslets, some other
>>> applications directly under the root context.
>> hmm I don't see why mapping /ows/* to the Dispatcher would avoid
>> adding /whatever in the future?
>>
>>>> That would allow you to do whatever you want from /<context>/ows
>>>> onwards, like /<context>/ows/<workspace>/wfs, etc.
>>>>
>>>> It sounds good to me, the only catch being possible applications
>>>> hardcoded to hit /<context>/wfs?
>>>>
>>>> What do you think?
>>> With this approach we would still be hardcoding the set of "root
>>> paths". For instance consider adding a new restful service. It has to
>>> go under "/rest" or "/api".
>> So it looks like I was not aware the virtual services affect rest too?
>> do you need /<workspace>/rest the same you need /<workspace>/wfs?
>>
>> Anyhow, if I just misunderstood it forget about that.
>>
>> Cheers,
>> Gabriel
>>
>> While this might not seem such bad restriction to
>>> some, to others it would seem strange. Some of the people doing
>>> javascript work that have to consume a geoserver restful service have
>>> commented on this before.
>>>
>>> Another example would be someone who wanted to experiment with a new
>>> sort of web front end. They would have to create a mapping in web.xml
>>> that is there only for the sole purpose of the extension.
>>>> 2c.-
>>>>
>>>> Gabriel
>>
>>
>
>

Re: the servlet-mapping problem

2009-12-17T08:49:47Z

Gabriel Roldan wrote:
> So you're chasing for a general solution to avoid servlet mappings in
> web.xml? I thought it was just about the virtual services being hard to
> map as conceived because it would force the /* mapping to ows.
Yes, i am looking in general although my immediate problem is only for
ows services.
>
> So I meant you can map /ows/* to the dispatcher and from that on
> introduce the virtual services

Right, but if you look at the way the proposal was written you will
notice the "virtual service"/workspace comes before the ows/wfs/wms/etc...

/geoserver/topp/ows?service=wfs&...

And yes I agree that for this *specific* problem we could just invert
them. But aesthetically I like the url structure the way as written in
the proposal so I am interested in pursuing this solution. Inverting the
urls to /geoserver/ows/topp is a fallback i am considering if this
proposed solution goes nowhere.

>
>> I am not quite sure I understand what you are getting at. I agree that
>> the "wms", "wfs", and "wcs" mappings can be considered as aliases for
>> "ows". But that seems sort of orthogonal to the problem. Even if we
>> disallowed them we would still have the same problem just one level up
>> not being able to add services, reslets, some other applications
>> directly under the root context.
> hmm I don't see why mapping /ows/* to the Dispatcher would avoid adding
> /whatever in the future?
>
>>
>>>
>>> That would allow you to do whatever you want from /<context>/ows
>>> onwards, like /<context>/ows/<workspace>/wfs, etc.
>>>
>>> It sounds good to me, the only catch being possible applications
>>> hardcoded to hit /<context>/wfs?
>>>
>>> What do you think?
>>
>> With this approach we would still be hardcoding the set of "root
>> paths". For instance consider adding a new restful service. It has to
>> go under "/rest" or "/api".
> So it looks like I was not aware the virtual services affect rest too?
> do you need /<workspace>/rest the same you need /<workspace>/wfs?

No. Forget virtual services for the context of this problem :) Apologies
for confusing two issues. This problem is:

a) to allow services to plug in under the root context without modifying
web.xml

b) to allow for more complex mappings, ie /*/ows/** rather than just /ows/*

>
> Anyhow, if I just misunderstood it forget about that.
>
> Cheers,
> Gabriel
>
> While this might not seem such bad restriction to
>> some, to others it would seem strange. Some of the people doing
>> javascript work that have to consume a geoserver restful service have
>> commented on this before.
>>
>> Another example would be someone who wanted to experiment with a new
>> sort of web front end. They would have to create a mapping in web.xml
>> that is there only for the sole purpose of the extension.
>>>
>>> 2c.-
>>>
>>> Gabriel
>>
>
>

Re: the servlet-mapping problem

2009-12-17T08:41:05Z

The thing is, mapping /*/wfs/* might also mean trouble if any other
resource has a "wfs" step?

Gabriel Roldan wrote:

> So you're chasing for a general solution to avoid servlet mappings in
> web.xml? I thought it was just about the virtual services being hard to
> map as conceived because it would force the /* mapping to ows.
>
> So I meant you can map /ows/* to the dispatcher and from that on
> introduce the virtual services
>
>> I am not quite sure I understand what you are getting at. I agree that
>> the "wms", "wfs", and "wcs" mappings can be considered as aliases for
>> "ows". But that seems sort of orthogonal to the problem. Even if we
>> disallowed them we would still have the same problem just one level up
>> not being able to add services, reslets, some other applications
>> directly under the root context.
> hmm I don't see why mapping /ows/* to the Dispatcher would avoid adding
> /whatever in the future?
>
>>> That would allow you to do whatever you want from /<context>/ows
>>> onwards, like /<context>/ows/<workspace>/wfs, etc.
>>>
>>> It sounds good to me, the only catch being possible applications
>>> hardcoded to hit /<context>/wfs?
>>>
>>> What do you think?
>> With this approach we would still be hardcoding the set of "root paths".
>> For instance consider adding a new restful service. It has to go under
>> "/rest" or "/api".
> So it looks like I was not aware the virtual services affect rest too?
> do you need /<workspace>/rest the same you need /<workspace>/wfs?
>
> Anyhow, if I just misunderstood it forget about that.
>
> Cheers,
> Gabriel
>
> While this might not seem such bad restriction to
>> some, to others it would seem strange. Some of the people doing
>> javascript work that have to consume a geoserver restful service have
>> commented on this before.
>>
>> Another example would be someone who wanted to experiment with a new
>> sort of web front end. They would have to create a mapping in web.xml
>> that is there only for the sole purpose of the extension.
>>> 2c.-
>>>
>>> Gabriel
>
>

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T08:37:55Z

So you're chasing for a general solution to avoid servlet mappings in
web.xml? I thought it was just about the virtual services being hard to
map as conceived because it would force the /* mapping to ows.

So I meant you can map /ows/* to the dispatcher and from that on
introduce the virtual services

> I am not quite sure I understand what you are getting at. I agree that
> the "wms", "wfs", and "wcs" mappings can be considered as aliases for
> "ows". But that seems sort of orthogonal to the problem. Even if we
> disallowed them we would still have the same problem just one level up
> not being able to add services, reslets, some other applications
> directly under the root context.
hmm I don't see why mapping /ows/* to the Dispatcher would avoid adding
/whatever in the future?

>
>>
>> That would allow you to do whatever you want from /<context>/ows
>> onwards, like /<context>/ows/<workspace>/wfs, etc.
>>
>> It sounds good to me, the only catch being possible applications
>> hardcoded to hit /<context>/wfs?
>>
>> What do you think?
>
> With this approach we would still be hardcoding the set of "root paths".
> For instance consider adding a new restful service. It has to go under
> "/rest" or "/api".

So it looks like I was not aware the virtual services affect rest too?
do you need /<workspace>/rest the same you need /<workspace>/wfs?

Anyhow, if I just misunderstood it forget about that.

Cheers,
Gabriel

While this might not seem such bad restriction to

> some, to others it would seem strange. Some of the people doing
> javascript work that have to consume a geoserver restful service have
> commented on this before.
>
> Another example would be someone who wanted to experiment with a new
> sort of web front end. They would have to create a mapping in web.xml
> that is there only for the sole purpose of the extension.
>>
>> 2c.-
>>
>> Gabriel
>

Re: the servlet-mapping problem

2009-12-17T08:19:34Z

Gabriel Roldan wrote:

> Hi,
>
> interesting problem
>
> As far as I can tell, we're not forced to keep /<context>/wfs,
> /<context>/wms, etc. The service entry points are really stated in the
> capabilities and /<context>/wfs is actually a shortcut for
> /<context>/ows?SERVICE=WFS, right? That is, no application _should_ be
> hardcoded to hit /<context>/wfs. If at all, the canonical entry point
> should be /<context>/ows.

True but I can guarantee that there are many clients and applications
that don't do this and go straight to a specific operation.
>
> So, as the OWS Dispatcher is there precisely to dispatch OWS requests,
> why don't we invert the mapping for "/<context>/ows" being the single
> entry point and /<context>/ows/wfs, for example, being the shortcut for
> /<context>/ows?service=WFS?

I am not quite sure I understand what you are getting at. I agree that
the "wms", "wfs", and "wcs" mappings can be considered as aliases for
"ows". But that seems sort of orthogonal to the problem. Even if we
disallowed them we would still have the same problem just one level up
not being able to add services, reslets, some other applications
directly under the root context.

>
> That would allow you to do whatever you want from /<context>/ows
> onwards, like /<context>/ows/<workspace>/wfs, etc.
>
> It sounds good to me, the only catch being possible applications
> hardcoded to hit /<context>/wfs?
>
> What do you think?

With this approach we would still be hardcoding the set of "root paths".
For instance consider adding a new restful service. It has to go under
"/rest" or "/api". While this might not seem such bad restriction to
some, to others it would seem strange. Some of the people doing
javascript work that have to consume a geoserver restful service have
commented on this before.

Another example would be someone who wanted to experiment with a new
sort of web front end. They would have to create a mapping in web.xml
that is there only for the sole purpose of the extension.
>
> 2c.-
>
> Gabriel

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: the servlet-mapping problem

2009-12-17T08:03:08Z

Hi,

interesting problem

As far as I can tell, we're not forced to keep /<context>/wfs,
/<context>/wms, etc. The service entry points are really stated in the
capabilities and /<context>/wfs is actually a shortcut for
/<context>/ows?SERVICE=WFS, right? That is, no application _should_ be
hardcoded to hit /<context>/wfs. If at all, the canonical entry point
should be /<context>/ows.

So, as the OWS Dispatcher is there precisely to dispatch OWS requests,
why don't we invert the mapping for "/<context>/ows" being the single
entry point and /<context>/ows/wfs, for example, being the shortcut for
/<context>/ows?service=WFS?

That would allow you to do whatever you want from /<context>/ows
onwards, like /<context>/ows/<workspace>/wfs, etc.

It sounds good to me, the only catch being possible applications
hardcoded to hit /<context>/wfs?

What do you think?

2c.-

Gabriel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

the servlet-mapping problem

2009-12-17T07:46:21Z

Hi all,

First off a warning that this is a long email :)

In doing the virtual service work (GSIP 44) i have yet again have run up
against a problem we have had in GeoServer ever since we moved to
spring. The problem being that we have to register all servlet mappings
in web.xml.

To describe the problem in more detail the following is how a request is
routed/dispatched in GeoServer today. In web.xml we register a single
servlet (DispatcherServlet) which is the spring dispatcher servlet. This
servlet essentially handles all requests that come into geoserver. But
it can only do so if the proper servlet mappings are registered web.xml.
For example:

<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/web/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/wms/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/wfs/*</url-pattern>
</servlet-mapping>

With these mappings a request that comes in of the form "/geoserver/wfs"
for example, will get routed to our one servlet to rule them all, the
spring dispatcher.

When handling a request the spring dispatcher takes the request and does
its down routing. It does this by looking up mappings in the spring
applicationContext.xml. For example the wfs mappings:

<bean id="wfsURLMapping" ...>
<property name="alwaysUseFullPath" value="true"/>
<property name="mappings">
<props>
<prop key="/wfs">dispatcher</prop>
<prop key="/wfs/*">dispatcher</prop>
</props>
</property>
</bean>

Which basically says map all urls of the form "/wfs*" to the ows dispatcher.

Now there are a couple of problems with this approach:

1) It is redundant in that we have to maintain two sets of mappings.

2) New services are not truly pluggable because any time one adds a new
path prefix web.xml has to be updated.

3) Mapping in web.xml is quite limited compared to the corresponding
spring mappings

(3) is where my problem lies with regard to the virtual services stuff.
To sum up with virtual services the path of a wfs request changes to:

/geoserver/<workspace>/wfs?

Which of course does not have a mapping in web.xml therefore the request
does not even make it to the spring dispatcher.

So the obvious solution (one that we have tried) would be to create a
single mapping in web.xml that matches all requests to the spring
dispatcher. The syntax is quite simple:

<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

But it does not work. The reason being that when this mapping is applied
some attributes of the resulting HttpServletRequest change. Namely the
"servletPath" property.

With the existing mappings when a request comes in the servlet path gets
set to the part of the path that matched. For example "web", "rest",
"wfs", etc... But with the "catch all" mapping the servlet path becomes
an empty string. I should also point out that this is the behavior in
Jetty and Tomcat, i have yet to try out other containers.

And this causes problem. Many of the libraries/servets we use depend on
the servlet path being set. Wicket and restlet pretty much fail
outright. So.... the evil plan to fix. I tried a variety fo things but
the following is only one i have had any success with.

Basically the idea is simple. Wrap the HttpServletRequest object in one
that fakes the servlet path. Since all the existing mappings are simple
in that they match a single patch component the wrapper class simply
expects the entire request uri and uses the first component of the path
(that occurs after /geoserver) and uses that for the servlet path.

So for wicket and restlet things go on working the same as the servlet
paths become "web" and "rest" the way they were before. And same goes
for the ows services.

Things get interesting when we get to the virtual services use case.
Since the path is (for example):

/geoserver/<workspace>/wfs

The servlet path becomes "<workspace>". To amend this the "second level
mappings" in the application context have to change a bit:

<bean id="wfsURLMapping" ...>
<property name="alwaysUseFullPath" value="true"/>
<property name="mappings">
<props>
<prop key="/wfs">dispatcher</prop>
<prop key="/wfs/*">dispatcher</prop>
<prop key="/*/wfs">dispatcher</prop>
<prop key="/*/wfs/*">dispatcher</prop>
</props>
</property>
</bean>

And with that it all works. So what do we do. I will be the first to
admit that this approach is a bit hackish. And I plan to do a great deal
of more testing in various environments to ensure it is actually even
viable. But if it is what do people think about it?

If the idea does get some uptake I was thinking we could gradually
introduce it as we have some of the other recent functionality
improvements such as advanced rendering functionality, etc... Basically
add a parameter (settable as system prop, web.xml context variable,
etc..) called "ADVANCED_DISPATCH" or something that would enable the
above. We could enable it on trunk and give it time to mature but
disable it by default on 2.0.x, making it available only by explicitly
setting the parameter.

Thoughts?

-Justin

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Build failed in Hudson: geoserver-trunk #2237

2009-12-17T06:44:04Z

See <http://hudson.opengeo.org/hudson/job/geoserver-trunk/2237/>

------------------------------------------
[...truncated 21963 lines...]
PARAMETER["central_meridian", -93.0],
PARAMETER["latitude_of_origin", 0.0],
PARAMETER["scale_factor", 0.9996],
PARAMETER["false_easting", 500000.0],
PARAMETER["false_northing", 0.0],
UNIT["m", 1.0],
AXIS["Easting", EAST],
AXIS["Northing", NORTH],
AUTHORITY["EPSG","32615"]]-->
<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Polygons" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:Ponds</Name>
<Title>Ponds</Title>
<Abstract>abstract about Ponds</Abstract>
<KeywordList>
<Keyword>Ponds</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Ponds</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Ponds" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>sf:PrimitiveGeoFeature</Name>
<Title>PrimitiveGeoFeature</Title>
<Abstract>abstract about PrimitiveGeoFeature</Abstract>
<KeywordList>
<Keyword>PrimitiveGeoFeature</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=PrimitiveGeoFeature" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:RoadSegments</Name>
<Title>RoadSegments</Title>
<Abstract>abstract about RoadSegments</Abstract>
<KeywordList>
<Keyword>RoadSegments</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>RoadSegments</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=RoadSegments" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cdf:Seven</Name>
<Title>Seven</Title>
<Abstract>abstract about Seven</Abstract>
<KeywordList>
<Keyword>Seven</Keyword>
</KeywordList>
<SRS>EPSG:32615</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Seven" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cite:Streams</Name>
<Title>Streams</Title>
<Abstract>abstract about Streams</Abstract>
<KeywordList>
<Keyword>Streams</Keyword>
</KeywordList>
<SRS>EPSG:4326</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<BoundingBox SRS="EPSG:4326" maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Streams</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Streams" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
<Layer queryable="1">
<Name>cdf:Updates</Name>
<Title>Updates</Title>
<Abstract>abstract about Updates</Abstract>
<KeywordList>
<Keyword>Updates</Keyword>
</KeywordList>
<SRS>EPSG:32615</SRS>

<LatLonBoundingBox maxx="180.0" maxy="90.0" minx="-180.0" miny="-90.0"/>
<Style>
<Name>Default</Name>
<Title>Default Styler</Title>
<Abstract/>
<LegendURL height="20" width="20">
<Format>image/png</Format>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://localhost/proxy/wms?request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=Updates" xlink:type="simple"/>
</LegendURL>
</Style>
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities>
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.47 sec
Running org.vfny.geoserver.wms.requests.DescribeLayerKvpRequestReaderTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.vfny.geoserver.wms.responses.featureinfo.FeatureTemplateTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.353 sec

Results :

Failed tests:
testRemoteOWSGet(org.vfny.geoserver.wms.responses.map.png.GetMapTest)

Tests run: 167, Failures: 1, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.

Please refer to <http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/wms/target/surefire-reports> for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 minutes 24 seconds
[INFO] Finished at: Thu Dec 17 09:44:03 EST 2009
[INFO] Final Memory: 43M/115M
[INFO] ------------------------------------------------------------------------

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jira] Created: (GEOS-3728) Adding Time and Elevation to GetFeatureInfo operation (for rasters only)

2009-12-17T04:33:55Z

Adding Time and Elevation to GetFeatureInfo operation (for rasters only)
------------------------------------------------------------------------

Key: GEOS-3728
URL: http://jira.codehaus.org/browse/GEOS-3728
Project: GeoServer
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani
Fix For: 2.0.x, 2.1.x

Adding Time and Elevation to GetFeatureInfo operation (for rasters only)

--
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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Test report on app-schema in 2.0.1 release candidate: PASS

2009-12-16T23:38:33Z

I tested the following components for 2.0.x (from the 2009-12-16 nightly
build):
geoserver-2.0.x-2009-12-16-war.zip
geoserver-2.0.1-SNAPSHOT-app-schema-plugin.zip
geoserver-2.0.1-SNAPSHOT-oracle-plugin.zip

The test configuration was:
geoserver-pirsa-earthresource-config.2009-08-11.r431.zip
https://twiki.auscope.org/twiki/bin/view/Grid/PirsaEarthResourceGeoserver

This configuration tests six app-schema feature types connecting to an
Oracle database via a JNDI connection pool. Note: dbtype was changed to
"oracle" to workaround GEOT-2598 ("Oracle" no longer works via JNDI).

I used apache-tomcat-6.0.20 under Sun Java 6 64-bit (jdk1.6.0_16.x64) on
Fedora 11. I used Oracle ojdbc5.jar rather than the oracle14.jar shipped
with the oracle-plugin.

I was able to deploy and start GeoServer and obtain good WFS responses
for the six complex feature types.

Test result: PASS.

Next time we should tag before we test (e.g 2.0.1rc1), to avoid those
last minute changes with unintended consequences. ;-)

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Renamed web-security module

2009-12-16T14:14:28Z

... to just "security" to match the naming convention of the other web
modules. None of the maven references to it should change.

Please update your eclipse workspaces by reimporting the new module.

-Justin

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Loud warning: code freeze starting today :-)

2009-12-16T07:28:04Z

Hi,
since we're going to release next week it should
be freeze time.

Which does not mean no commits at all btw, it means
no commits unless you're fixing a critical bug

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel