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.
What about just having JAIInfo.jai be lazily evaluated, and have it just return the JAI singleton directly. JAI.getDefaultInstance() doesn’t seem to be an expensive lookup at all (just returns a static singleton), so having it be called continuously should not be an issue.
On Sun, Jan 1, 2012 at 8:12 PM, Gabriel Roldan <groldan@anonymised.com501…> wrote:
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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Jan 2, 2012 at 6:22 PM, Justin Deoliveira <jdeolive@anonymised.com1501…> wrote:
What about just having JAIInfo.jai be lazily evaluated, and have it just return the JAI singleton directly. JAI.getDefaultInstance() doesn’t seem to be an expensive lookup at all (just returns a static singleton), so having it be called continuously should not be an issue.
Agreed. However I guess we should setup some rule about what *Info object are allowed to keep state (as a field)
and which ones cannot
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Please take note that GeoSolutions will be closed for Christmas holidays from 27/12 to 30/12
On Mon, Jan 2, 2012 at 2:33 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Mon, Jan 2, 2012 at 6:22 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
What about just having JAIInfo.jai be lazily evaluated, and have it just
return the JAI singleton directly. JAI.getDefaultInstance() doesn't seem to
be an expensive lookup at all (just returns a static singleton), so having
it be called continuously should not be an issue.
You mean JAIInfoImpl.getJAI(){ return JAI.getDefaultInstance();} ?
Guess it'd work. Still I'd be up to avoiding any non configuration
object as part of the configuration API. But feel free to implement it
that way or give me the go ahead and I'll do it myself. I suppose the
change should come along with the deprecation of JAIInfo.setJAI(JAI)?
Cheers,
Gabriel
Agreed. However I guess we should setup some rule about what *Info object
are allowed to keep state (as a field)
and which ones cannot
Cheers
Andrea
On Mon, Jan 2, 2012 at 1:06 PM, Gabriel Roldan <groldan@…1501…> wrote:
On Mon, Jan 2, 2012 at 2:33 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Mon, Jan 2, 2012 at 6:22 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
What about just having JAIInfo.jai be lazily evaluated, and have it just
return the JAI singleton directly. JAI.getDefaultInstance() doesn’t seem to
be an expensive lookup at all (just returns a static singleton), so having
it be called continuously should not be an issue.
You mean JAIInfoImpl.getJAI(){ return JAI.getDefaultInstance();} ?
Guess it’d work. Still I’d be up to avoiding any non configuration
object as part of the configuration API. But feel free to implement it
that way or give me the go ahead and I’ll do it myself. I suppose the
change should come along with the deprecation of JAIInfo.setJAI(JAI)?
Yeah, I try to avoid it as well… , but that was how the interface was designed from day one so seems the path of least resistance. The api does employ for things like derived properties and such that aren’t strictly “configuration” or plain regular properties.
Feel free to proceed how you see fit. I guess I would say change getJAI() as we discussed directly on JAIInfo. As for deprecating setJAI()… i am fine with that as well… although we could just leave the property settable. A third alternative would be to make it a derived properly, deprecate both getJAI() and setJAI() and replace with jai().
Maybe in the interest of you moving forward just update getJAI() and we discuss the rest further? Up to you.
Cheers,
Gabriel
Agreed. However I guess we should setup some rule about what *Info object
are allowed to keep state (as a field)
and which ones cannot
Cheers
Andrea
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.