Thanks for the explanation Gabriel. When those changes are integrated to the 2.1.x branch would it be posible to download a nightly build from geoserver.org and then just drop the geoserver-geonode.jar plugin in the right directory to do the auth override?
If that is the case, do you think it would make sense to put such a plugin as a community module in GeoServer and take it out of the github repo? In my humble opinion we could start with a community module, then in a few months try to become an extension and find our way into the default extensions bundled with GeoServer, so that people can enable GeoNode compliance with just setting the GEONODE_BASE_URL in web.xml or the environment. I am going to think more about this and try to come up with a more complete proposal, but would love to hear feedback from the community. Ariel. > The situation will be reverted to depend on vanilla geoserver 2.1.x > branch once it's open for new developments again (i.e. after the 2.1.0 > release of geoserver, which should be next week). > > Does that answer your question? > > Cheers, > Gabriel >> >> >> >> Thanks, >> >> Christian >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of David Winslow >> Sent: Friday, May 06, 2011 9:54 AM >> To: [email protected] >> Subject: Re: [geonode] GeoNode stability and the 1.1 release series >> >> >> >> >> Yes, we need to use a custom build of GeoServer in order to allow >> GeoServer to respect Django's user system instead of its own. If you >> want to talk about how to make GeoNode work with an uncustomized >> GeoServer we can have that discussion, but I am not convinced it is a >> big problem: apart from ignoring the security/ subdirectory of the >> datadir, GeoNode's GeoServer reads the same configuration files. If >> you do need an unmodified GeoServer, could you explain a bit more >> about why that's the case? >> >> >> >> >> -- >> >> >> David Winslow >> >> >> OpenGeo - http://opengeo.org/ >> >> On Fri, May 6, 2011 at 9:45 AM, Spanring, Christian >> <[email protected]> wrote: >> >> Thanks David, that sounds fantastic! >> >> >> >> One quick question: will GeoNode 1.1 still depend on a custom build of >> GeoServer (as 1.0) or will 1.1 be able to use a regular GeoServer 2.1 >> build? >> >> >> >> Christian >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of David Winslow >> Sent: Thursday, May 05, 2011 4:53 PM >> To: [email protected] >> Subject: [geonode] GeoNode stability and the 1.1 release series >> >> >> >> >> Hi all, >> >> >> >> >> We've already mentioned this in passing to some folks on this mailing >> list, but just to officially publicize it: we are no longer planning >> any further releases from the GeoNode 1.0 series. The PSC has >> discussed this and the next release will be 1.1-beta. >> >> >> >> >> >> The main reason for this decision is that investigations into the >> stability of GeoNode have reached a point where the most promising >> options open to us are reliant on the 2.1.x release series of >> GeoServer (two examples being the GWC integration which greatly >> decreases GeoNode's resource consumption, and the control-flow module >> which also reduces resource consumption (in a different way.) However, >> the features already implemented on the 1.1 release series are already >> compelling: >> >> >> * GeoServer 2.1 (many improvements including better raster >> handling and tight GeoWebCache integration) >> * UI Improvements (previously intended as the main improvement >> for the 1.0.1 release.) >> * Improved GeoNode security system (caching, more reliable >> technique for overriding GeoServer's builtin security) >> * Performance improvements in the gsconfig Python module used >> for syncing the Django and GeoServer layer info >> * Cookie-awareness for OWSLib (a cookie workaround is already >> implemented in GeoNode, but if the patch submitted to OWSLib >> is accepted in time then we will be using "native" cookie >> support) >> * The upload functionality in GeoNode will be "refactored" >> providing better reliability and, importantly, error reporting >> to assist troubleshooting. Thanks to the Risiko team for >> these improvements. >> * Upload-to-PostGIS functionality in the upload form (gsconfig >> already has support for this and we expect a patch for the >> GeoNode code that uses it before the beta release. Thanks to >> the Worldmap team for this.) >> * Improved Unit and Integration testing suites for the Django >> components of GeoNode, including a Continuous Integration >> server to ensure that all changes that go into the GeoNode >> core are tested, regardless of potentially forgetful >> developers. >> We would like to put the release out after the upcoming roadmapping >> summit to be held in Washington DC. It is tentatively scheduled for >> May 27. Ariel, Seb, and I will be sprinting on "sprucing up" the >> synth branch in anticipation of the release during the week of May 16 >> (right before the summit.) >> >> >> >> >> >> In the interim, there are some configuration changes that can be made >> on GeoNode 1.0 installations to improve their stability, although even >> with these changes we have seen some outages. We'll provide a more >> detailed writeup soon but in short: >> >> >> * There is a patch available which greatly improves the way that >> the Django component communicates with GeoNetwork. >> * Constraining the number of concurrent requests GeoServer will >> attempt to serve simultaneously will help to avoid OOM >> exceptions. >> * Some additional configuration can greatly improve the >> speed with which GeoServer handles requests, allowing it to >> have fewer concurrent requests (each request spends less time >> being handled so fewer of them must be handled at a time for >> the same request volume.) >> There is also an experimental branch of gsconfig.py which reduces >> internal traffic within GeoNode. This is a drop-in replacement for >> the gsconfig module included with GeoNode 1.0, but is not as >> well-tested (unit test coverage is the same but it hasn't been tested >> much "in the field"). I would be interested in reports from any users >> who try this out. It is a 100% reversible modification so if it >> doesn't work for you it is straightforward to switch back. >> >> >> >> >> >> Again, we will be providing detailed instructions for applying these >> changes; they just have not yet been written up. >> >> >> >> >> >> -- >> >> >> David Winslow >> >> >> OpenGeo - http://opengeo.org >> >> >> >> >> >> ______________________________________________________________________ >> Please be advised that the Massachusetts Secretary of State considers >> e-mail to be a public record, and therefore subject to the >> Massachusetts Public Records Law, M.G.L. c. 66 § 10. >> >> >> >> >> > > -- > Gabriel Roldan > [email protected] > Expert service straight from the developers > >
