With the rush for FOSS4G in full swing and most efforts pushing towards a final release of 2.0, we’re happy to announce that the GeoServer stable series (1.7.x) is still receiving the love it deserves.  Today we see the release of GeoServer 1.7.7 into the wild.  Though there is a relatively short list of bug fixes, a few of the rare but critical leaks have been plugged, and various improvements have been made to the REST configuration API, imagemosaic plugins, and the shapefile output format.

We encourage you to point your browser to the download site and give it a try, and as always, we are keen to hear any feedback you my have.

I am pleased to announce that we are organizing a “Birds of a Feather” session (what’s that?) at the FOSS4G 2009 Conference in Sydney, Australia. This session is to gather together everyone who is interested in discussing the past, present, and (bright) future of GeoServer.

The session will be held on Thursday 22nd October, late afternoon (specific time TBD). If you are attending FOSS4G 2009 (and you very much should), feel free to stop by in order to say hi and chat a bit with us.

See you there!

The GeoServer community is happy to announce the formation of an official Testing Team.

The Testing Team is a set of users and developers that will install and run impending GeoServer releases prior to their official distribution. The purpose is to provide real-world testing, something that developers alone can not provide.

Approximately once a month, a development freeze will be called and the Testing Team will install and run the most recent nightly build. Each tester in the team will use GeoServer in his or her unique environment and will check that important features are working as expected, and that regressions (features that used to work but now do not) have not appeared, with developers standing by to fix any regressions that may be uncovered. For example, someone will test that uDig still works against the GeoServer releases, someone else will test against ArcSDE, some will test for performance, and so on.

Are you interested? **Everybody can participate in the testing process. No development skills are required. ** All you have to do is to read the Official Testing Team proposal, drop in on the GeoServer developer mailing list (yes, even if you’re not a developer), introduce yourself and your desire to participate.

We want you to know that as development on GeoServer continues, we are trying to make sure that we are fulfilling the needs of the community. We want to make upgrading a seamless, hassle-free experience, and we feel that creating a team of testers is the best way to ensure this. The more people who join our team, the better GeoServer will become.

Let’s improve GeoServer together! Join us!

I thought it would have been worth spending a few minutes to let people know about this development that we are performing at GeoSolutions. Being not only GeoServer developers but also GeoServer hungry users, we have been a bit unpleased in the past some the scalability problems that it was showing due to the fact that:

1. GeoServer was keeping all its configuration into memory

2. GeoServer was making use XML files to handle its internal configuration

Now a lot of work has been lately for the upcoming 2.0 version of GeoServer, to cope with point 2 above, however point 2 has not been touched yet. If you use GeoServer the way we use it, with thousand of layers and with 10 to 100 new layers added daily (usually remote sensing data), you might agree with us that we need to:

1. Not load and keep the entire configuration in memory

2. Use a database to store the configuration

In a few words, we need to improve scalability and robustness while tring to not jeopardize performance, we need to be enterprise-ready.

At GeoSolutions we have decided to tackle this problems by implementing a new GeoServer internal catalog that leverages on Hibernate as its persistence engine and that would also not bring the whole configuration into memory. Our goal is to be able to support at least Postgis and Oracle as the target database, but as you know, many more are supported by Hibernate (spatialite wi  ontheradar as well). The range of features that this work would open up is pretty wide, just think about using Hibernate distributed caching, simplified GeoServer replication, etc., etc.

The work is in progress, we have started to describe the details on the GeoServer wiki . If you are interesting in supporting somehow (funding or human resources) this effort, please, drop me a few lines at simone.giannecchiniATgeo-solutions.it.

We have been using JBoss extensively in the last two years in order deploy GeoServer along with some custom extensions as well as a few other proprietary application. Lately we have started to experiment a bit with JBoss 5.x and since people seem to have problems deplying GeoServer in it weput together a post on our compay blog (see here) with some basic instructions on how to deploy GeoServer 1.7.6 inside JBoss 5.1.

If you you need help wrestling with JBoss, feel free to contact us!