Thanks Arne; the background is very useful. I actually should be joining your mailing list next week for a separate project I am working on.
Two responses: - The basic wicket page sounds okay - it meets my requirement for "showing up" in the user interface - What you describe is an interesting set up - it sounds like you have no actual dependencies on GeoServer code ... indeed the same functionality could be deployed as two separate WARs can it not? Reading about your plans for the RESTful interfaces; what are you actually trying to access? Jody Arne Kepp wrote: > Currently: > It's not really a geoserver extension at this point, it's more like a > separate servlet that uses the same Spring context to load. It doesn't > change GeoServer's behavior, much less present a configuration page. > > The only configuration variable that most people have to set is > GEOSERVER_DATA_DIR. If GeoServer is not accessible through > http://localhost:8080/geoserver you'll also have to set > GEOSERVER_WMS_URL, but that's pretty much all you can do for the > "plugin" version. Both of these values are set in web.xml or as > environment variables. > > See http://geoserver.org/display/GEOSDOC/GeoWebCache > > In the near future: > For the next two weeks one of our recently hired developers will try > to build a UI for it using OpenLayers and ExtJS. (This combo is chosen > because Tim Schaub has already built applications with it that come > close to doing what I think we want). It will go on top of the RESTful > interface that Marius Suta has been working on over the summer (GSOC). > I'm currently going through those changes and testing. > > We also want to have GWC listen for GS configuration changes > (read-only). So when we add that I guess we can make a wicket page > that outputs basic information about the GWC plugin and a link to the > JavaScript UI. I don't think making a complete UI in Wicket is realistic. > > -Arne > > > Justin Deoliveira wrote: >> Jody Garnett wrote: >> >>> Justin Deoliveira wrote: >>> >>>> Anyways, yes I see your point, there is always a case for a UI. I >>>> agree with that. Its just I don't think it should be a blocker. I >>>> mean.. .if it is we can say bye bye to bundling geowebcache with >>>> GeoServer... since it has no UI. >>>> >>> Interesting; GeoWebCache must have some kind of configuration? >>> - A directory it writes files into? >>> - Tile size? >>> - does it have some log settings we can change >>> - does it have anything? >>> >> It has its own configuration files, but i am actually not sure if >> they are read when its bundled with GeoServer, i think it >> auto-configures itself from a WMS capabilities doc. >> >>> Let me try for a real small minimum; can we have a page showing the >>> currently loaded "extensions" and if they have been loaded correctly? >>> I would like to visually communicate what is going on to the user; >>> for community modules it is not a big deal - but for an extension I >>> want something to change somewhere at least acknowledging the >>> existence of the extension. >>> >> Again a good idea... but not easy to do. This isn't osgi, we don't >> have a true plug-in system with a class representing a plug-in or >> extension that we can just lookup. >> >> Instead of trying to add all these requirements up-front and make the >> process "heavyweight" from the start can we approach these as >> "todo's". We have a good process in place that will get us off the >> ground. Everyone speculating about stuff that we "will need" does not >> seem all that useful at this point. I mean... these are really good >> idea's, but i would prefer that we come back to them when they >> actually become an issue. For instance if we get a bunch of >> extensions and cant tell what he heck is going on, whats loaded and >> what's not, then i say we come back and re-evaulate the process. >> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
