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. > >> Jody >> >> ------------------------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------------------------- 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
