Hello, as I've been working on an alternate catalog/config backend (aka, CatalogFacade and GeoServerFacade, which I'll write more about in the coming days), found the JAI settings hard to be retained for any GeoServerFacade implementations that's not the default (memory) one, just because JAI is not part of the config objects, but a singleton instance assumed to be there as per org.geoserver.config.JAIInfo.getJAI():JAI
To be more clear, the current design kind of assumes the JAIInitializer will set the JAI instance on the GeoServerInfo's JAIInfo and it will remain there (JAI is a transient instance field in JAIInfoImpl, for instance), whilst that may be not true for any non memory back end. I think a better option would be if the configured JAI instance was part of the GeoServer(Impl) singleton (l.e. GeoServer.getJAI() instead of GeoServerInfo.getJaiInfo().getJAI() ) A workaround could be made so that the GeoServerFacade holds the JAI instance internally whenever the global GeoServerInfo is saved and sets it back to the returned GeoServerInfo instance whenever it is requested, but that seems hacky and misplaced. Opinions? Cheers, Gabriel. P.S. sorry for the pretty unclear explanation, kind of sleepy right now. -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
