[Geoserver-devel] Geoserver-devel Digest, Vol 53, Issue 24

Hi!

I have a simple question for you, does GeoServer supported by Openlayers, how I can retrieve layer data which created by GeoServer from OpenLayers?

Openlayers.layer.GeoServer(… )

Thank you !

Zhanping


From:geoserver-devel-request@lists.sourceforge.netgeoserver-devel-request@lists.sourceforge.net
To: geoserver-devel@lists.sourceforge.net
Sent: Tue, October 12, 2010 8:35:09 PM
Subject: Geoserver-devel Digest, Vol 53, Issue 24

Send Geoserver-devel mailing list submissions to
geoserver-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
or, via email, send a message with subject or body ‘help’ to
geoserver-devel-request@lists.sourceforge.net

You can reach the person managing the list at
geoserver-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than “Re: Contents of Geoserver-devel digest…”

Today’s Topics:

  1. Re: how to package a datastore plugin? (Ian Turton)
  2. [jira] Created: (GEOS-4173) does not work proxy extention
    module (Lazarev Eugene (JIRA))
  3. Re: how to package a datastore plugin? (Justin Deoliveira)
  4. Re: upgrading to wicket 1.4 (Justin Deoliveira)
  5. Re: upgrading to wicket 1.4 (Ben Caradoc-Davies)

Message: 1
Date: Tue, 12 Oct 2010 12:08:51 -0400
From: Ian Turton <ijturton@anonymised.com>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Justin Deoliveira <jdeolive@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>, David
Winslow <dwinslow@anonymised.com>
Message-ID:
<AANLkTimHAaNrKqMCX7sE2iOio=RFVca1x48AXsMG0Ksn@anonymised.com>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

For future reference this is actually decently documented in the developer
guide.
http://docs.geoserver.org/stable/en/developer/policies/community-modules.html

What I’m missing is what the maven command I need to execute to build
the zip file is and/or where to look for the zip file?

Plus there are a couple of errors on that page where … warning is
not being processed probably a missing blank line.

Ian

Ian Turton


Message: 2
Date: Tue, 12 Oct 2010 13:48:32 -0500 (CDT)
From: “Lazarev Eugene (JIRA)” <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-4173) does not work
proxy extention module
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<11043648.79102.1286909312611.JavaMail.haus-jira@anonymised.com>

Content-Type: text/plain; charset=ISO-8859-1

does not work proxy extention module

Key: GEOS-4173
URL: http://jira.codehaus.org/browse/GEOS-4173
Project: GeoServer
Issue Type: Bug
Components: Configuration, Global, REST
Affects Versions: 2.1-beta1, 2.0.2
Environment: proxy-2.0.3-SNAPSHOT
rest-2.0.3-SNAPSHOT
geoserver 2.0.2
Reporter: Lazarev Eugene
Assignee: Justin Deoliveira
Attachments: GeoServer_Demo_requests.png, GeoServer_Demo_requests_proxy.png, GeoServer_Geoserver_Proxy_Administration.png

I tried to everything, all of that does not help, I could not get it to work, I think this is a bug.
you can log on to http://svn.ugi.ru:1580/geoserver/
login: admin
pass: geoserver
to test it


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


Message: 3
Date: Tue, 12 Oct 2010 13:26:07 -0600
From: Justin Deoliveira <jdeolive@anonymised.com>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Ian Turton <ijturton@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>, David
Winslow <dwinslow@anonymised.com>
Message-ID:
<AANLkTimTwUtSr17-HxuTFs7fJM-hdx3TXbwgGPJ16cMv@anonymised.com>
Content-Type: text/plain; charset=“iso-8859-1”

If you have the release descriptor written (ext-whatever.xml) and it is
lives in either release or community/release you must update either pom.xml
or community/pom.xml to add it to list of descriptors that get an artifact
built. Just search for ext-*.xml in the file.

Then you do a mvn assembly:attached from either the root of source tree or
root of community depending on where your descriptor lives. The result will
be a zip file under target/release.

-Justin

On Tue, Oct 12, 2010 at 10:08 AM, Ian Turton <ijturton@anonymised.com> wrote:

On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

For future reference this is actually decently documented in the
developer
guide.

http://docs.geoserver.org/stable/en/developer/policies/community-modules.html

What I’m missing is what the maven command I need to execute to build
the zip file is and/or where to look for the zip file?

Plus there are a couple of errors on that page where … warning is
not being processed probably a missing blank line.

Ian

Ian Turton


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed…


Message: 4
Date: Tue, 12 Oct 2010 13:28:06 -0600
From: Justin Deoliveira <jdeolive@anonymised.com>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Andrea Aime <andrea.aime@anonymised.com>
Cc: geoserver-devel@lists.sourceforge.net
Message-ID:
<AANLkTikr66R0w6Pc-hrELnRW8QzBPaBToABCMOU7Gd1F@anonymised.com>
Content-Type: text/plain; charset=“iso-8859-1”

Cool, so far we have 2 +0’s and 1 +1. So seems there is some interest.

So pushing forward I guess we should:

(a) flush out the rest of the key errors by manually visiting all pages
(adding test cases along the way)
(b) write up an official proposal for the purpose of voting

Sound good?

On Tue, Oct 12, 2010 at 3:23 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Tue, Oct 12, 2010 at 1:26 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hi all,
Recently i have come across a few extensions for wicket that I figure
would
be nice but require wicket 1.4. That and since 1.4 seems to be the
current
stable release I thought I would take a crack at an upgrade. Not the
easiest
upgrade by a long shot but I have a working setup in my github repo [1].
Before describing what I did I am curious to hear what people think about
an
upgrade? Is now the right time? Or should we push off to 2.2? Personally
i
guess i am +0 on the upgrade. On the one hand there are no crucial issues
that will be fixed by the upgrade, if anything we will still have issues
as
i am sure there are cases where keys are being referenced that do not
exist
in the property file. we just don’t have the test coverage to catch it.
Before this patch goes through every single page will have to visited
manually… that or we up test coverage to 100% :slight_smile: But on the other hand
95%
of the work is done and if we don’t upgrade now the patch will become
outdated, etc…

I’m favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
far away and Wicket 1.4 would be replaced by 1.5 by then.
I prefer to see a “one step at a time” approach and switch to Wicket 1.4
before
GeoServer beta2 is relased.

  1. LayerGroupEditPageTest
    This one i was actually not sure about. It seems the test makes
    some assumptions about how the layer list is structured and perhaps it
    changed.

a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java

+++

b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java

@@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
LayerGroupBaseTest {
tester.assertRenderedPage(LayerGroupEditPage.class);
// remove the first and second elements

tester.clickLink(“form:layers:layers:listContainer:items:1:itemProperties:4:component:link”);

// the regenerated list will have ids starting from 4

tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);

//tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);

// manually regenerate bounds
tester.clickLink(“form:generateBounds”);
// print(page, true, true);

Hopefully the author can chime in.

Yeah, to click a link in a list container we need to go through the
full path, I know of no
other way to make it work. What you can do is to use the debug
facilities in our testing
harness to have the structure of the page be printed and see how the
new link path
looks like. See print(Compoenent, boolean, boolean)

  1. CoverageStoreEditPageTest,DataAccessEditPageTest
    These pages have custom validator on the form that check the data store
    name
    to ensure that it (a) gets set and (b) does not already exist in the
    catalog. There is also the validator that gets implicitly set since the
    “name” field is required. It seems the order in which they execute is now
    different and the latter executes first. For example:

a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java

+++

b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java

@@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
GeoServerWicketTestSupport {
tester.clickLink(“rasterStoreForm:save”);

tester.assertRenderedPage(CoverageStoreEditPage.class);

  • tester.assertErrorMessages(new String { “Store name is
    required”
    });
  • tester.assertErrorMessages(new String { “Field ‘Data Source
    Name’
    is required.” });
    }

Ah, I see. Patch looks good.

Btw, also had a quick look at the full patch on github, looks good too.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed…


Message: 5
Date: Wed, 13 Oct 2010 08:34:57 +0800
From: Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Justin Deoliveira <jdeolive@anonymised.com>
Cc: “geoserver-devel@lists.sourceforge.net
<geoserver-devel@lists.sourceforge.net>, Andrea Aime
<andrea.aime@anonymised.com>
Message-ID: <4CB4FEB1.1070808@anonymised.com>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

Sounds good to me. Count me as +1.

On 13/10/10 03:28, Justin Deoliveira wrote:

Cool, so far we have 2 +0’s and 1 +1. So seems there is some interest.

So pushing forward I guess we should:

(a) flush out the rest of the key errors by manually visiting all pages (adding test cases along the way)
(b) write up an official proposal for the purpose of voting

Sound good?

On Tue, Oct 12, 2010 at 3:23 AM, Andrea Aime<andrea.aime@anonymised.commailto:[andrea.aime@anonymised.com](mailto:andrea.aime@anonymised.com)> wrote:
On Tue, Oct 12, 2010 at 1:26 AM, Justin Deoliveira<jdeolive@anonymised.commailto:[jdeolive@anonymised.com](mailto:jdeolive@anonymised.com)> wrote:

Hi all,
Recently i have come across a few extensions for wicket that I figure would
be nice but require wicket 1.4. That and since 1.4 seems to be the current
stable release I thought I would take a crack at an upgrade. Not the easiest
upgrade by a long shot but I have a working setup in my github repo [1].
Before describing what I did I am curious to hear what people think about an
upgrade? Is now the right time? Or should we push off to 2.2? Personally i
guess i am +0 on the upgrade. On the one hand there are no crucial issues
that will be fixed by the upgrade, if anything we will still have issues as
i am sure there are cases where keys are being referenced that do not exist
in the property file. we just don’t have the test coverage to catch it.
Before this patch goes through every single page will have to visited
manually… that or we up test coverage to 100% :slight_smile: But on the other hand 95%
of the work is done and if we don’t upgrade now the patch will become
outdated, etc…

I’m favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
far away and Wicket 1.4 would be replaced by 1.5 by then.
I prefer to see a “one step at a time” approach and switch to Wicket 1.4 before
GeoServer beta2 is relased.

  1. LayerGroupEditPageTest
    This one i was actually not sure about. It seems the test makes
    some assumptions about how the layer list is structured and perhaps it
    changed.

a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
+++
b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
@@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
LayerGroupBaseTest {
tester.assertRenderedPage(LayerGroupEditPage.class);
// remove the first and second elements

tester.clickLink(“form:layers:layers:listContainer:items:1:itemProperties:4:component:link”);
// the regenerated list will have ids starting from 4

tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);
+
//tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);
// manually regenerate bounds
tester.clickLink(“form:generateBounds”);
// print(page, true, true);

Hopefully the author can chime in.

Yeah, to click a link in a list container we need to go through the
full path, I know of no
other way to make it work. What you can do is to use the debug
facilities in our testing
harness to have the structure of the page be printed and see how the
new link path
looks like. See print(Compoenent, boolean, boolean)

  1. CoverageStoreEditPageTest,DataAccessEditPageTest
    These pages have custom validator on the form that check the data store name
    to ensure that it (a) gets set and (b) does not already exist in the
    catalog. There is also the validator that gets implicitly set since the
    “name” field is required. It seems the order in which they execute is now
    different and the latter executes first. For example:

a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
+++
b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
@@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
GeoServerWicketTestSupport {
tester.clickLink(“rasterStoreForm:save”);

tester.assertRenderedPage(CoverageStoreEditPage.class);

  • tester.assertErrorMessages(new String { “Store name is required”
    });
  • tester.assertErrorMessages(new String { “Field ‘Data Source Name’
    is required.” });
    }

Ah, I see. Patch looks good.

Btw, also had a quick look at the full patch on github, looks good too.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



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


Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre



Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

End of Geoserver-devel Digest, Vol 53, Issue 24


You can use the standard wms or wfs layer from openlayers. Check out the openlayers examples for example code.

-Justin

On Tue, Oct 12, 2010 at 8:29 PM, Zhanping Shi <zhanpings@anonymised.com> wrote:

Hi!

I have a simple question for you, does GeoServer supported by Openlayers, how I can retrieve layer data which created by GeoServer from OpenLayers?

Openlayers.layer.GeoServer(… )

Thank you !

Zhanping


From:geoserver-devel-request@anonymised.comeforge.net” <geoserver-devel-request@anonymised.comnet>
To: geoserver-devel@anonymised.comurceforge.net
Sent: Tue, October 12, 2010 8:35:09 PM
Subject: Geoserver-devel Digest, Vol 53, Issue 24

Send Geoserver-devel mailing list submissions to
geoserver-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
or, via email, send a message with subject or body ‘help’ to
geoserver-devel-request@lists.sourceforge.net

You can reach the person managing the list at
geoserver-devel-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than “Re: Contents of Geoserver-devel digest…”

Today’s Topics:

  1. Re: how to package a datastore plugin? (Ian Turton)
  2. [jira] Created: (GEOS-4173) does not work proxy extention
    module (Lazarev Eugene (JIRA))
  3. Re: how to package a datastore plugin? (Justin Deoliveira)
  4. Re: upgrading to wicket 1.4 (Justin Deoliveira)
  5. Re: upgrading to wicket 1.4 (Ben Caradoc-Davies)

Message: 1
Date: Tue, 12 Oct 2010 12:08:51 -0400
From: Ian Turton <ijturton@anonymised.com>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Justin Deoliveira <jdeolive@anonymised.com…1501…>
Cc: Geoserver-devel <geoserver-devel@anonymised.comrge.net>, David
Winslow <dwinslow@anonymised.com>
Message-ID:
<AANLkTimHAaNrKqMCX7sE2iOio=RFVca1x48AXsMG0Ksn@anonymised.com>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

For future reference this is actually decently documented in the developer
guide.
http://docs.geoserver.org/stable/en/developer/policies/community-modules.html

What I’m missing is what the maven command I need to execute to build
the zip file is and/or where to look for the zip file?

Plus there are a couple of errors on that page where … warning is
not being processed probably a missing blank line.

Ian

Ian Turton


Message: 2
Date: Tue, 12 Oct 2010 13:48:32 -0500 (CDT)
From: “Lazarev Eugene (JIRA)” <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-4173) does not work
proxy extention module
To: geoserver-devel@anonymised.comet
Message-ID:
<11043648.79102.1286909312611.JavaMail.haus-jira@anonymised.com>

Content-Type: text/plain; charset=ISO-8859-1

does not work proxy extention module

Key: GEOS-4173
URL: http://jira.codehaus.org/browse/GEOS-4173
Project: GeoServer
Issue Type: Bug
Components: Configuration, Global, REST
Affects Versions: 2.1-beta1, 2.0.2
Environment: proxy-2.0.3-SNAPSHOT
rest-2.0.3-SNAPSHOT
geoserver 2.0.2
Reporter: Lazarev Eugene
Assignee: Justin Deoliveira
Attachments: GeoServer_Demo_requests.png, GeoServer_Demo_requests_proxy.png, GeoServer_Geoserver_Proxy_Administration.png

I tried to everything, all of that does not help, I could not get it to work, I think this is a bug.
you can log on to http://svn.ugi.ru:1580/geoserver/
login: admin
pass: geoserver
to test it


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


Message: 3
Date: Tue, 12 Oct 2010 13:26:07 -0600
From: Justin Deoliveira <jdeolive@anonymised.com>
Subject: Re: [Geoserver-devel] how to package a datastore plugin?
To: Ian Turton <ijturton@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@anonymised.com.sourceforge.net>, David
Winslow <dwinslow@anonymised.com>
Message-ID:
<AANLkTimTwUtSr17-HxuTFs7fJM-hdx3TXbwgGPJ16cMv@anonymised.com>
Content-Type: text/plain; charset=“iso-8859-1”

If you have the release descriptor written (ext-whatever.xml) and it is
lives in either release or community/release you must update either pom.xml
or community/pom.xml to add it to list of descriptors that get an artifact
built. Just search for ext-*.xml in the file.

Then you do a mvn assembly:attached from either the root of source tree or
root of community depending on where your descriptor lives. The result will
be a zip file under target/release.

-Justin

On Tue, Oct 12, 2010 at 10:08 AM, Ian Turton <ijturton@anonymised.com> wrote:

On Tue, Oct 12, 2010 at 8:50 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

For future reference this is actually decently documented in the
developer
guide.

http://docs.geoserver.org/stable/en/developer/policies/community-modules.html

What I’m missing is what the maven command I need to execute to build
the zip file is and/or where to look for the zip file?

Plus there are a couple of errors on that page where … warning is
not being processed probably a missing blank line.

Ian

Ian Turton


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed…


Message: 4
Date: Tue, 12 Oct 2010 13:28:06 -0600
From: Justin Deoliveira <jdeolive@anonymised.com>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Andrea Aime <andrea.aime@…1268…>
Cc: geoserver-devel@lists.sourceforge.net
Message-ID:
<AANLkTikr66R0w6Pc-hrELnRW8QzBPaBToABCMOU7Gd1F@anonymised.com>
Content-Type: text/plain; charset=“iso-8859-1”

Cool, so far we have 2 +0’s and 1 +1. So seems there is some interest.

So pushing forward I guess we should:

(a) flush out the rest of the key errors by manually visiting all pages
(adding test cases along the way)
(b) write up an official proposal for the purpose of voting

Sound good?

On Tue, Oct 12, 2010 at 3:23 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

On Tue, Oct 12, 2010 at 1:26 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hi all,
Recently i have come across a few extensions for wicket that I figure
would
be nice but require wicket 1.4. That and since 1.4 seems to be the
current
stable release I thought I would take a crack at an upgrade. Not the
easiest
upgrade by a long shot but I have a working setup in my github repo [1].
Before describing what I did I am curious to hear what people think about
an
upgrade? Is now the right time? Or should we push off to 2.2? Personally
i
guess i am +0 on the upgrade. On the one hand there are no crucial issues
that will be fixed by the upgrade, if anything we will still have issues
as
i am sure there are cases where keys are being referenced that do not
exist
in the property file. we just don’t have the test coverage to catch it.
Before this patch goes through every single page will have to visited
manually… that or we up test coverage to 100% :slight_smile: But on the other hand
95%
of the work is done and if we don’t upgrade now the patch will become
outdated, etc…

I’m favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
far away and Wicket 1.4 would be replaced by 1.5 by then.
I prefer to see a “one step at a time” approach and switch to Wicket 1.4
before
GeoServer beta2 is relased.

  1. LayerGroupEditPageTest
    This one i was actually not sure about. It seems the test makes
    some assumptions about how the layer list is structured and perhaps it
    changed.

a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java

+++

b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java

@@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
LayerGroupBaseTest {
tester.assertRenderedPage(LayerGroupEditPage.class);
// remove the first and second elements

tester.clickLink(“form:layers:layers:listContainer:items:1:itemProperties:4:component:link”);

// the regenerated list will have ids starting from 4

tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);

//tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);

// manually regenerate bounds
tester.clickLink(“form:generateBounds”);
// print(page, true, true);

Hopefully the author can chime in.

Yeah, to click a link in a list container we need to go through the
full path, I know of no
other way to make it work. What you can do is to use the debug
facilities in our testing
harness to have the structure of the page be printed and see how the
new link path
looks like. See print(Compoenent, boolean, boolean)

  1. CoverageStoreEditPageTest,DataAccessEditPageTest
    These pages have custom validator on the form that check the data store
    name
    to ensure that it (a) gets set and (b) does not already exist in the
    catalog. There is also the validator that gets implicitly set since the
    “name” field is required. It seems the order in which they execute is now
    different and the latter executes first. For example:

a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java

+++

b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java

@@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
GeoServerWicketTestSupport {
tester.clickLink(“rasterStoreForm:save”);

tester.assertRenderedPage(CoverageStoreEditPage.class);

  • tester.assertErrorMessages(new String { “Store name is
    required”
    });
  • tester.assertErrorMessages(new String { “Field ‘Data Source
    Name’
    is required.” });
    }

Ah, I see. Patch looks good.

Btw, also had a quick look at the full patch on github, looks good too.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed…


Message: 5
Date: Wed, 13 Oct 2010 08:34:57 +0800
From: Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com.>
Subject: Re: [Geoserver-devel] upgrading to wicket 1.4
To: Justin Deoliveira <jdeolive@…1501…>
Cc: “geoserver-devel@lists.sourceforge.net
<geoserver-devel@lists.sourceforge.net>, Andrea Aime
<andrea.aime@anonymised.com>
Message-ID: <4CB4FEB1.1070808@anonymised.com>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed

Sounds good to me. Count me as +1.

On 13/10/10 03:28, Justin Deoliveira wrote:

Cool, so far we have 2 +0’s and 1 +1. So seems there is some interest.

So pushing forward I guess we should:

(a) flush out the rest of the key errors by manually visiting all pages (adding test cases along the way)
(b) write up an official proposal for the purpose of voting

Sound good?

On Tue, Oct 12, 2010 at 3:23 AM, Andrea Aime<andrea.aime@anonymised.commailto:[andrea.aime@anonymised.com](mailto:andrea.aime@anonymised.com.)> wrote:
On Tue, Oct 12, 2010 at 1:26 AM, Justin Deoliveira<jdeolive@anonymised.commailto:[jdeolive@anonymised.com.](mailto:jdeolive@anonymised.com)> wrote:

Hi all,
Recently i have come across a few extensions for wicket that I figure would
be nice but require wicket 1.4. That and since 1.4 seems to be the current
stable release I thought I would take a crack at an upgrade. Not the easiest
upgrade by a long shot but I have a working setup in my github repo [1].
Before describing what I did I am curious to hear what people think about an
upgrade? Is now the right time? Or should we push off to 2.2? Personally i
guess i am +0 on the upgrade. On the one hand there are no crucial issues
that will be fixed by the upgrade, if anything we will still have issues as
i am sure there are cases where keys are being referenced that do not exist
in the property file. we just don’t have the test coverage to catch it.
Before this patch goes through every single page will have to visited
manually… that or we up test coverage to 100% :slight_smile: But on the other hand 95%
of the work is done and if we don’t upgrade now the patch will become
outdated, etc…

I’m favourable to have the patchset hit GeoServer now. GeoServer 2.2 is far
far away and Wicket 1.4 would be replaced by 1.5 by then.
I prefer to see a “one step at a time” approach and switch to Wicket 1.4 before
GeoServer beta2 is relased.

  1. LayerGroupEditPageTest
    This one i was actually not sure about. It seems the test makes
    some assumptions about how the layer list is structured and perhaps it
    changed.

a/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
+++
b/web/core/src/test/java/org/geoserver/web/data/layergroup/LayerGroupEditPageTest.java
@@ -13,8 +13,9 @@ public class LayerGroupEditPageTest extends
LayerGroupBaseTest {
tester.assertRenderedPage(LayerGroupEditPage.class);
// remove the first and second elements

tester.clickLink(“form:layers:layers:listContainer:items:1:itemProperties:4:component:link”);
// the regenerated list will have ids starting from 4

tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);
+
//tester.clickLink(“form:layers:layers:listContainer:items:4:itemProperties:4:component:link”);
// manually regenerate bounds
tester.clickLink(“form:generateBounds”);
// print(page, true, true);

Hopefully the author can chime in.

Yeah, to click a link in a list container we need to go through the
full path, I know of no
other way to make it work. What you can do is to use the debug
facilities in our testing
harness to have the structure of the page be printed and see how the
new link path
looks like. See print(Compoenent, boolean, boolean)

  1. CoverageStoreEditPageTest,DataAccessEditPageTest
    These pages have custom validator on the form that check the data store name
    to ensure that it (a) gets set and (b) does not already exist in the
    catalog. There is also the validator that gets implicitly set since the
    “name” field is required. It seems the order in which they execute is now
    different and the latter executes first. For example:

a/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
+++
b/web/core/src/test/java/org/geoserver/web/data/store/CoverageStoreEditPageTest.java
@@ -55,7 +57,7 @@ public class CoverageStoreEditPageTest extends
GeoServerWicketTestSupport {
tester.clickLink(“rasterStoreForm:save”);

tester.assertRenderedPage(CoverageStoreEditPage.class);

  • tester.assertErrorMessages(new String { “Store name is required”
    });
  • tester.assertErrorMessages(new String { “Field ‘Data Source Name’
    is required.” });
    }

Ah, I see. Patch looks good.

Btw, also had a quick look at the full patch on github, looks good too.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



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


Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre



Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb



Geoserver-devel mailing list
Geoserver-devel@anonymised.comrceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

End of Geoserver-devel Digest, Vol 53, Issue 24



Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


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