[Geoserver-devel] Trunk bugs?

Hey all,

I've been playing with geoserver-trunk lately, and went to go and see how far 2.2.x got in terms of putting in rendering patches that I submitted a while ago. So I set up geoserver-trunk using GEOSERVER_DATA_DIR (pointing to my old 1.3.x data dir) and tried to edit one of the existing featuretypes. Big struts error.

Then I tried to add a new ArcSDE featuretype, and the 'generate' button didn't actually generate anything into the lat/long bbox.

Then I manually entered the values, created the featuretype, and went to request a map using XML-POST.

Got this exception:

org.vfny.geoserver.wms.WmsException: Method getXmlRequestReader() not yet implemented.

Do I have something misconfigured, or is this expected?

I'll file JIRA bugs on all of these, but I guess this is just a heads up that it looks like things are a ways off from anything other than an "alpha" release of the 1.4 stuff. Actually, I'm not sure that I'd vote +1 on a release of any sort of the 1.4 stuff till some of these more major bugs are worked out (i.e., that's 1.4 is largely usable).

Then again, that's why it'd just be a milestone release, right?

--saul

Great work Saul, comments inline.

Saul Farber wrote:

Hey all,

I've been playing with geoserver-trunk lately, and went to go and see how far 2.2.x got in terms of putting in rendering patches that I submitted a while ago. So I set up geoserver-trunk using GEOSERVER_DATA_DIR (pointing to my old 1.3.x data dir) and tried to edit one of the existing featuretypes. Big struts error.

Yeah, there could definitley be some UI issues, if there is any where we are lacking test wise, it is hand testing the ui. Can you include a strack trace or point me to the jira and I can check it out.

Then I tried to add a new ArcSDE featuretype, and the 'generate' button didn't actually generate anything into the lat/long bbox.

I would throw my money into that this is a datastore CRS problem. Can you replicate the issue with a differnt datastore?

Then I manually entered the values, created the featuretype, and went to request a map using XML-POST.

Got this exception:

org.vfny.geoserver.wms.WmsException: Method getXmlRequestReader() not yet implemented.

I am not sure if this is a bug, I think that this is something that just never got implemented. Does the spec support POST for a get map, i know that the body of the request is used to store the sld document.

Do I have something misconfigured, or is this expected?

I'll file JIRA bugs on all of these, but I guess this is just a heads up that it looks like things are a ways off from anything other than an "alpha" release of the 1.4 stuff. Actually, I'm not sure that I'd vote +1 on a release of any sort of the 1.4 stuff till some of these more major bugs are worked out (i.e., that's 1.4 is largely usable).

Thanks Saul, this QA is really great. We have passed all conformance tests, however we still lack some good old fashioned hand testing. I have tried to get 1.3.x onto trunk in order to flush out these issues but there is resistance until that first "stable" release, the good old chicken and the egg.

So yeah hopefully this milestone can bring us in all the bug reports we need to get things up to par.

Then again, that's why it'd just be a milestone release, right?

--saul

-Justin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44d0f6a1327011804284693!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Hi all,
I’m going to commit on trunk all the bug fixes to the UI too … I’ll do it tomorrw :slight_smile:

On 8/2/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Great work Saul, comments inline.

Saul Farber wrote:

Hey all,

I’ve been playing with geoserver-trunk lately, and went to go and see
how far 2.2.x got in terms of putting in rendering patches that I
submitted a while ago. So I set up geoserver-trunk using
GEOSERVER_DATA_DIR (pointing to my old 1.3.x data dir) and tried to edit
one of the existing featuretypes. Big struts error.
Yeah, there could definitley be some UI issues, if there is any where we
are lacking test wise, it is hand testing the ui. Can you include a
strack trace or point me to the jira and I can check it out.

Then I tried to add a new ArcSDE featuretype, and the ‘generate’ button
didn’t actually generate anything into the lat/long bbox.
I would throw my money into that this is a datastore CRS problem. Can
you replicate the issue with a differnt datastore?

Then I manually entered the values, created the featuretype, and went to
request a map using XML-POST.

Got this exception:

org.vfny.geoserver.wms.WmsException: Method getXmlRequestReader() not
yet implemented.
I am not sure if this is a bug, I think that this is something that just
never got implemented. Does the spec support POST for a get map, i know
that the body of the request is used to store the sld document.

Do I have something misconfigured, or is this expected?

I’ll file JIRA bugs on all of these, but I guess this is just a heads up
that it looks like things are a ways off from anything other than an
“alpha” release of the 1.4 stuff. Actually, I’m not sure that I’d vote
+1 on a release of any sort of the 1.4 stuff till some of these more
major bugs are worked out (i.e., that’s 1.4 is largely usable).

Thanks Saul, this QA is really great. We have passed all conformance
tests, however we still lack some good old fashioned hand testing. I
have tried to get 1.3.x onto trunk in order to flush out these issues
but there is resistance until that first “stable” release, the good old
chicken and the egg.

So yeah hopefully this milestone can bring us in all the bug reports we
need to get things up to par.

Then again, that’s why it’d just be a milestone release, right?

–saul

-Justin


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


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

!DSPAM:1004,44d0f6a1327011804284693!


Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys – and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


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

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it


Cool! What's up with syncronization between 1.4.x_merge_wcs and trunk? Are you cross-merging fairly often, or is mostly one-way (bugfixes on merge_wcs go to trunk?)

Just curious!
--saul

Alessio Fabiani wrote:

Hi all,
I'm going to commit on trunk all the bug fixes to the UI too ... I'll do it tomorrw :slight_smile:

For the moment only bugfixes will go to trunk … the wcs branch is costantly aligned with trunk however … very soon (I hope) a new GeoServer version will be released, 1.5.x, with wcs module too.

There are still some problems with the module:

  1. The UI interface is not modular as well. I’m studying a way to solve this problem; I’ll do a proposal to the PSC asap.
  2. The GeoServer trunk is alredy based on GeoTools 2.2-RC5-SNAPSHOT while wcs is based on GeoTools trunk, i.e. 2.3-SNAPSHOT. I think however that soon there will be an intermediate GeoServer trunk release based on GeoTools trunk.

On 8/2/06, Saul Farber <Saul.Farber@anonymised.com> wrote:

Cool! What’s up with syncronization between 1.4.x_merge_wcs and trunk?
Are you cross-merging fairly often, or is mostly one-way (bugfixes on
merge_wcs go to trunk?)

Just curious!
–saul

Alessio Fabiani wrote:

Hi all,
I’m going to commit on trunk all the bug fixes to the UI too … I’ll do
it tomorrw :slight_smile:

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it


Justin Deoliveira ha scritto:

Great work Saul, comments inline.

Saul Farber wrote:
  

Hey all,

I've been playing with geoserver-trunk lately, and went to go and see how far 2.2.x got in terms of putting in rendering patches that I submitted a while ago. So I set up geoserver-trunk using GEOSERVER_DATA_DIR (pointing to my old 1.3.x data dir) and tried to edit one of the existing featuretypes. Big struts error.
    

Yeah, there could definitley be some UI issues, if there is any where we are lacking test wise, it is hand testing the ui.

Well, it's not that is impossible to automatically test ui, but yes, it's hard.
See:
http://httpunit.sourceforge.net/
http://www.openqa.org/selenium/

Andrea Aime

Alessio Fabiani ha scritto:

For the moment only bugfixes will go to trunk ... the wcs branch is costantly aligned with trunk however ... very soon (I hope) a new GeoServer version will be released, 1.5.x, with wcs module too.
There are still some problems with the module:
1) The UI interface is not modular as well. I'm studying a way to solve this problem; I'll do a proposal to the PSC asap.

Interesting, can you keep me in the loop?
I've been thinking about wicket, but see also this: http://www.eclipse.org/proposals/rsp/
(they are looking for modular web frameworks as well)
Cheers
Andrea

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Great work Saul, comments inline.

Saul Farber wrote:
  

Hey all,

I've been playing with geoserver-trunk lately, and went to go and see how far 2.2.x got in terms of putting in rendering patches that I submitted a while ago. So I set up geoserver-trunk using GEOSERVER_DATA_DIR (pointing to my old 1.3.x data dir) and tried to edit one of the existing featuretypes. Big struts error.
    

Yeah, there could definitley be some UI issues, if there is any where we are lacking test wise, it is hand testing the ui.

Well, it's not that is impossible to automatically test ui, but yes, it's hard.
See:
http://httpunit.sourceforge.net/
http://www.openqa.org/selenium/

I've heard good things about selenium, some of our plone developers make use of it here.

Chris

Andrea Aime

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44d10f1913332207481331!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Andrea Aime wrote:

Alessio Fabiani ha scritto:

For the moment only bugfixes will go to trunk ... the wcs branch is costantly aligned with trunk however ... very soon (I hope) a new GeoServer version will be released, 1.5.x, with wcs module too.
There are still some problems with the module:
1) The UI interface is not modular as well. I'm studying a way to solve this problem; I'll do a proposal to the PSC asap.

Interesting, can you keep me in the loop?
I've been thinking about wicket, but see also this: http://www.eclipse.org/proposals/rsp/
(they are looking for modular web frameworks as well)

Very cool.

'Will RSP-UI work with Spring?

RSP-UI invites contributions by the Spring community to enable the use of Spring within RSP-UI applications. Work is ongoing in the Spring community to provide use of Spring with OSGi by Spring Release version 3.'

Also three of the 9 initial committers are about wicket enablement.

C

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44d10fac14087731818748!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Yes, I too have been on the search for a "pluggable" ui web technology but havent had much luck.

RSP looks like the next step in evelotion of equinox. When I did my initial research into a good framework to base geoserver on this was definitly up there. It just wasnt mature enough at the time. But this looks promising, worth the research.

-Justin

Andrea Aime wrote:

Alessio Fabiani ha scritto:

For the moment only bugfixes will go to trunk ... the wcs branch is costantly aligned with trunk however ... very soon (I hope) a new GeoServer version will be released, 1.5.x, with wcs module too.

There are still some problems with the module:
1) The UI interface is not modular as well. I'm studying a way to solve this problem; I'll do a proposal to the PSC asap.

Interesting, can you keep me in the loop?
I've been thinking about wicket, but see also this: http://www.eclipse.org/proposals/rsp/
(they are looking for modular web frameworks as well)
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44d10fac14101510810322!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com