[Geoserver-devel] Wicket updates?

GeoServer GeoServer Developer
1

Hey all, I haven’t looked at Wicket in a while but as I prepare to come back to it I have noticed that Wicket 6 is in beta (much like Java, the Wicket project is going straight from 1.5 to 6.0). GeoServer, however, is still pinned to version 1.4.12 (and even the 1.4 series has had several minor revisions since then; they’re at 1.4.20 already.)

Are there plans to update wicket? I imagine it’s too late for 2.2.x to go to Wicket 1.5 (maybe we should get those bugfix updates in) but maybe we should get this going for 2.3.x. Eclipse tells me there are around 200 compile errors trying to build the current sources against Wicket 1.5.7.

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

2

On Fri, Aug 10, 2012 at 4:30 PM, David Winslow <dwinslow@anonymised.com> wrote:

Hey all, I haven’t looked at Wicket in a while but as I prepare to come back to it I have noticed that Wicket 6 is in beta (much like Java, the Wicket project is going straight from 1.5 to 6.0). GeoServer, however, is still pinned to version 1.4.12 (and even the 1.4 series has had several minor revisions since then; they’re at 1.4.20 already.)

Are there plans to update wicket? I imagine it’s too late for 2.2.x to go to Wicket 1.5 (maybe we should get those bugfix updates in) but maybe we should get this going for 2.3.x. Eclipse tells me there are around 200 compile errors trying to build the current sources against Wicket 1.5.7.

I went through the same reasoning and tried out 1.5.x a few months ago, stumbled against the same amount of compile errors and gave up,
it was too much work to be done by me alone… maybe if there is enough people interested we could create a shared branch
on github and work on it as a team

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

3

Looking over the what’s new in either version I am tempted to jump straight to 6 once it is out of beta.

https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
http://wicketinaction.com/2012/07/whats-new-in-wicket-6/

That said I imagine it will much more work than going to 15 but it might be good to be slightly ahead of the curve to avoid having to coordinate an upgrade to 1.5 now and then try to coordinate an upgrade to 6 or some future version later.

$0.02

On Fri, Aug 10, 2012 at 8:55 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Aug 10, 2012 at 4:30 PM, David Winslow <dwinslow@anonymised.com> wrote:

Hey all, I haven’t looked at Wicket in a while but as I prepare to come back to it I have noticed that Wicket 6 is in beta (much like Java, the Wicket project is going straight from 1.5 to 6.0). GeoServer, however, is still pinned to version 1.4.12 (and even the 1.4 series has had several minor revisions since then; they’re at 1.4.20 already.)

Are there plans to update wicket? I imagine it’s too late for 2.2.x to go to Wicket 1.5 (maybe we should get those bugfix updates in) but maybe we should get this going for 2.3.x. Eclipse tells me there are around 200 compile errors trying to build the current sources against Wicket 1.5.7.

I went through the same reasoning and tried out 1.5.x a few months ago, stumbled against the same amount of compile errors and gave up,
it was too much work to be done by me alone… maybe if there is enough people interested we could create a shared branch
on github and work on it as a team

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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.

4

This makes sense to me. The 6.0.0 Beta 3 announcement cites that there are no more planned API changes so I guess we could start on that immediately.

In previous library updates for other projects I have done interim updates (for example, bringing GeoNode from Django 1.2.1 to 1.4 by updating to 1.2.5, fixing any errors, updating to 1.3, fixing any errors, updating to 1.4, fixing remaining errors.) I think a similar approach might make sense here - it probably takes longer overall, but it feels a bit less likely to introduce mystery bugs and has more “stop points” where things are mostly working. In Java, some libraries use @deprecated for pending API changes and make this pretty easy if you just follow the yellow flags in Eclipse.

We have some errors running tests against Wicket 1.4.20 so I think 1.4.20, 1.5.7, and 6.0 beta 3 would be good targets.

Anyway, I am interested in trying out the shared-branch approach. We could make a feature branch in the geoserver/geoserver repository on Github for this.

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

On Fri, Aug 10, 2012 at 12:28 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Looking over the what’s new in either version I am tempted to jump straight to 6 once it is out of beta.

https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
http://wicketinaction.com/2012/07/whats-new-in-wicket-6/

That said I imagine it will much more work than going to 15 but it might be good to be slightly ahead of the curve to avoid having to coordinate an upgrade to 1.5 now and then try to coordinate an upgrade to 6 or some future version later.

$0.02

On Fri, Aug 10, 2012 at 8:55 AM, Andrea Aime <andrea.aime@anonymised.com1268…> wrote:

On Fri, Aug 10, 2012 at 4:30 PM, David Winslow <dwinslow@anonymised.com> wrote:

Hey all, I haven’t looked at Wicket in a while but as I prepare to come back to it I have noticed that Wicket 6 is in beta (much like Java, the Wicket project is going straight from 1.5 to 6.0). GeoServer, however, is still pinned to version 1.4.12 (and even the 1.4 series has had several minor revisions since then; they’re at 1.4.20 already.)

Are there plans to update wicket? I imagine it’s too late for 2.2.x to go to Wicket 1.5 (maybe we should get those bugfix updates in) but maybe we should get this going for 2.3.x. Eclipse tells me there are around 200 compile errors trying to build the current sources against Wicket 1.5.7.

I went through the same reasoning and tried out 1.5.x a few months ago, stumbled against the same amount of compile errors and gave up,
it was too much work to be done by me alone… maybe if there is enough people interested we could create a shared branch
on github and work on it as a team

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

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

5

I went ahead and created a branch: https://github.com/geoserver/geoserver/tree/feature-upgrade-wicket

About coordinating on it, I don’t think we need a lot of collaboration - stick to fixing tests that are failing and it’ll be pretty unambiguous what needs to be done. I’ll try and pull master onto this branch periodically, that should make merging the other way pretty painless when the time comes.

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

On Fri, Aug 10, 2012 at 12:40 PM, David Winslow <dwinslow@anonymised.com> wrote:

This makes sense to me. The 6.0.0 Beta 3 announcement cites that there are no more planned API changes so I guess we could start on that immediately.

In previous library updates for other projects I have done interim updates (for example, bringing GeoNode from Django 1.2.1 to 1.4 by updating to 1.2.5, fixing any errors, updating to 1.3, fixing any errors, updating to 1.4, fixing remaining errors.) I think a similar approach might make sense here - it probably takes longer overall, but it feels a bit less likely to introduce mystery bugs and has more “stop points” where things are mostly working. In Java, some libraries use @deprecated for pending API changes and make this pretty easy if you just follow the yellow flags in Eclipse.

We have some errors running tests against Wicket 1.4.20 so I think 1.4.20, 1.5.7, and 6.0 beta 3 would be good targets.

Anyway, I am interested in trying out the shared-branch approach. We could make a feature branch in the geoserver/geoserver repository on Github for this.

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

On Fri, Aug 10, 2012 at 12:28 PM, Justin Deoliveira <jdeolive@anonymised.com1…> wrote:

Looking over the what’s new in either version I am tempted to jump straight to 6 once it is out of beta.

https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
http://wicketinaction.com/2012/07/whats-new-in-wicket-6/

That said I imagine it will much more work than going to 15 but it might be good to be slightly ahead of the curve to avoid having to coordinate an upgrade to 1.5 now and then try to coordinate an upgrade to 6 or some future version later.

$0.02

On Fri, Aug 10, 2012 at 8:55 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Aug 10, 2012 at 4:30 PM, David Winslow <dwinslow@anonymised.com01…> wrote:

Hey all, I haven’t looked at Wicket in a while but as I prepare to come back to it I have noticed that Wicket 6 is in beta (much like Java, the Wicket project is going straight from 1.5 to 6.0). GeoServer, however, is still pinned to version 1.4.12 (and even the 1.4 series has had several minor revisions since then; they’re at 1.4.20 already.)

Are there plans to update wicket? I imagine it’s too late for 2.2.x to go to Wicket 1.5 (maybe we should get those bugfix updates in) but maybe we should get this going for 2.3.x. Eclipse tells me there are around 200 compile errors trying to build the current sources against Wicket 1.5.7.

I went through the same reasoning and tried out 1.5.x a few months ago, stumbled against the same amount of compile errors and gave up,
it was too much work to be done by me alone… maybe if there is enough people interested we could create a shared branch
on github and work on it as a team

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

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

6

On Wed, Aug 15, 2012 at 11:10 PM, David Winslow <dwinslow@anonymised.com> wrote:

I went ahead and created a branch: https://github.com/geoserver/geoserver/tree/feature-upgrade-wicket

About coordinating on it, I don’t think we need a lot of collaboration - stick to fixing tests that are failing and it’ll be pretty unambiguous what needs to be done. I’ll try and pull master onto this branch periodically, that should make merging the other way pretty painless when the time comes.

Hi David,
just made a run through it and fixed a number of tests that were still failing with 1.4.20,
I believe I have the whole GUI working with 1.4.20 now, so I’m trying to jump onwards to 1.5.7

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

7

On Sat, Aug 18, 2012 at 6:02 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi David,
just made a run through it and fixed a number of tests that were still failing with 1.4.20,
I believe I have the whole GUI working with 1.4.20 now, so I’m trying to jump onwards to 1.5.7

Hi all,
so I’ve been working on moving that branch to 1.5.7.
The work to do so has proven to be substantive and painful so far: various classes we depended
on have been either renamed, severely refactored into new sets of classes, sometimes updated
in a way that makes them unusable for us, and sometimes even plainly removed without any
way to replace them.

The update has been so far following this update guide:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
which could be renamed “how to upgrade simple wicket applications in 200 easy steps”…
GeoServer of course does not fall into this category and tapped into Wicket internals
into lots of ways that made upgrading more difficult.

Here are some examples of what upgrading means.

PageParameters does not work the way it did anymore, you have to go through an
intermediate object now, and when filling it you cannot use a map anymore:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L58R30
and:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L11L72
(which opens the potential for NPE, did not look into it so far)

ResorceReference is now a abstract class, the one we used has been factored out
into PackageResoureReference:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L1R45

When using a feedback border around components you now have one more item in the component
paths, meaning all tests hitting one of such components have to be updated:
https://github.com/geoserver/geoserver/commit/d6c70346368648c8edaa17602c7bb9bb1c5fa603#L6L38

HeaderContribution is gone, it has to be replaced with an override of the Page renderHead method:
From this:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L3R80
to this:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L3R184

Returning a streaming response with a resource (image, file) is simply completely different now:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L11L98

All ajax links and buttons have to include a onError method when implemented (the method was there,
but not abstract, now it is):
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L13L156

Implementing a component visitor has changed significantly, now the visit is not controlled by the
return value but by a parameter of the visit call that controls what to do next:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L24L107

NumberValidator is gone, it’s now replaced by three different classes (min/max/range validator)
and has no more convenience instances for positive/negative checks:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L39R22

IBehavior is no more, now Behavior is a base class:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L42L49

The htmlvalidator utility, which we used to have a in-page report of xhtml validation, has been
modified a lot and now includes a reference to Saxon, which breaks solid our XML parsing.
I had to remove it, for HTML validation we’ll have to rely on browser plugins instead:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L0L40

URL encoding strategies are gone, now there is IRequestMapper that takes its place.
From this:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L4L0
to (hopefully working) this:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L5L-1

Ok, after all this, where are we? In the middle of an upgrade, web/core compiles but I haven’t got al tests
to pass so far, some are due to bugs in wicket tester that will be fixed in 1.5.8, others I still haven’t figured out.
Once that is done, there are the other web modules to upgrade and make compile and pass tests.

And then… we’ll need quite some time to do interactive testing I believe, the amount of changes is
large and the testing we have is light.

Given this I’m not so sure we want to also jump the 1.6.x series before it has stabilized a bit,
especially considering that extras outside of the core (wicket stuff, eventual jquery integrations
we might want to use to add some drag&drop support in the UI) usually lag behind and are
not ready for the .0 release.

Maybe that will be a job for GeoServer 2.4.0?

Anyways, I’m out of the pool till next weekend, if you want to give the thing a crack and fix
other compile errors/tests be my guest :slight_smile:

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

8

Thanks for looking into this and for the detailed report as well. Given the changes you cite I would tend to agree that bumping one major wicket version is probably all that is reasonable even for the master branch right now.

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

On Sun, Aug 19, 2012 at 2:16 PM, Andrea Aime <andrea.aime@anonymised.com.> wrote:

On Sat, Aug 18, 2012 at 6:02 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi David,
just made a run through it and fixed a number of tests that were still failing with 1.4.20,
I believe I have the whole GUI working with 1.4.20 now, so I’m trying to jump onwards to 1.5.7

Hi all,
so I’ve been working on moving that branch to 1.5.7.
The work to do so has proven to be substantive and painful so far: various classes we depended
on have been either renamed, severely refactored into new sets of classes, sometimes updated
in a way that makes them unusable for us, and sometimes even plainly removed without any
way to replace them.

The update has been so far following this update guide:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
which could be renamed “how to upgrade simple wicket applications in 200 easy steps”…
GeoServer of course does not fall into this category and tapped into Wicket internals
into lots of ways that made upgrading more difficult.

Here are some examples of what upgrading means.

PageParameters does not work the way it did anymore, you have to go through an
intermediate object now, and when filling it you cannot use a map anymore:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L58R30
and:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L11L72
(which opens the potential for NPE, did not look into it so far)

ResorceReference is now a abstract class, the one we used has been factored out
into PackageResoureReference:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L1R45

When using a feedback border around components you now have one more item in the component
paths, meaning all tests hitting one of such components have to be updated:
https://github.com/geoserver/geoserver/commit/d6c70346368648c8edaa17602c7bb9bb1c5fa603#L6L38

HeaderContribution is gone, it has to be replaced with an override of the Page renderHead method:
From this:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L3R80
to this:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L3R184

Returning a streaming response with a resource (image, file) is simply completely different now:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L11L98

All ajax links and buttons have to include a onError method when implemented (the method was there,
but not abstract, now it is):
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L13L156

Implementing a component visitor has changed significantly, now the visit is not controlled by the
return value but by a parameter of the visit call that controls what to do next:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L24L107

NumberValidator is gone, it’s now replaced by three different classes (min/max/range validator)
and has no more convenience instances for positive/negative checks:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L39R22

IBehavior is no more, now Behavior is a base class:
https://github.com/geoserver/geoserver/commit/8e1875588baac368e125020a1d727c7cb58d4f83#L42L49

The htmlvalidator utility, which we used to have a in-page report of xhtml validation, has been
modified a lot and now includes a reference to Saxon, which breaks solid our XML parsing.
I had to remove it, for HTML validation we’ll have to rely on browser plugins instead:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L0L40

URL encoding strategies are gone, now there is IRequestMapper that takes its place.
From this:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L4L0
to (hopefully working) this:
https://github.com/geoserver/geoserver/commit/c90ee17a1ab9122e538373c38473eb39270b8bbc#L5L-1

Ok, after all this, where are we? In the middle of an upgrade, web/core compiles but I haven’t got al tests
to pass so far, some are due to bugs in wicket tester that will be fixed in 1.5.8, others I still haven’t figured out.
Once that is done, there are the other web modules to upgrade and make compile and pass tests.

And then… we’ll need quite some time to do interactive testing I believe, the amount of changes is
large and the testing we have is light.

Given this I’m not so sure we want to also jump the 1.6.x series before it has stabilized a bit,
especially considering that extras outside of the core (wicket stuff, eventual jquery integrations
we might want to use to add some drag&drop support in the UI) usually lag behind and are
not ready for the .0 release.

Maybe that will be a job for GeoServer 2.4.0?

Anyways, I’m out of the pool till next weekend, if you want to give the thing a crack and fix
other compile errors/tests be my guest :slight_smile:

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it