On Thu, Mar 1, 2012 at 6:47 PM, Martin Davis <[email protected]> wrote: > Whew! I sort of followed that... However, my debugger shows that there is > only ONE copy of the process across all styles. Not sure how this changes > the thinking above.. But I was going to suggest that maybe it would be > best to simply create a new Process object for every rendering request. The > time for object creation is a fraction of the time for parameter marshalling > - not to mention the time for the process itself. That way there's less for > everyone to worry about (OO Rule #42 - Singletons are evil...)
Singletons in Spring are the rule for good reason (and they are not implemented as singletons, but the spring context keeps all beans up as general facilities). Feel free to find a way to get a process be created anew each time and make that avaiable either as an option and/or as the default (some processes might have a very high init setup time, so it cannot be the only option) >> > I am just not seeing how I can take advantage of the inveryQuery method >> > to >> > alter the query window as needed (and as the original proposal stated as >> > a >> > design goal). >> >> Mumble... if you directly implement a FilterFunction you should have the >> full list of arguments _before_ execute is called (since when the function >> the arguemnts are known) and... oh... >> Have a look at the RenderingProcess interface, which an annotated >> process can implement to get rendering transform support and... voilà, see >> the method signatures: >> >> Query invertQuery(Map<String, Object> input, Query targetQuery, >> GridGeometry gridGeometry) throws ProcessException; >> >> GridGeometry invertGridGeometry(Map<String, Object> input, Query >> targetQuery, >> GridGeometry targetGridGeometry) throws ProcessException; >> >> You actually get full access to the parameters in the map form. >> I believe that's what you're looking for. >> Doh, I added that interface over six months ago and I did not remember >> it was there > > > I realized this myself yesterday as well... (at least, I was assuming that > the map "input" was the input expressions, since it's not yet documented). > I was also confused by this because my Annotation-driven process is > receiving a null for that parameter. It turns out (I think) this is a bug > in the annotation-driven wrapper ( InvokeMethodRenderingProcess, line 544 - > the input map should be inserted directly into the args array, rather than > being passed through buildProcessArguments). Patches + tests welcomed > > BTW, I don't think an anno-driven process can implement the RenderingProcess > interface, since that requires implementing execute(Map...) as well - which > then gives two execute methods? Might be nice to make that interface a > mixin, rather than an extension of Process? Agreed. Have a look at what I did in the process that georeferences rasters on trunk, it is a rendering transformation. Probably some hack based on a naming convention. Again, patches + tests welcomed :-) 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 ------------------------------------------------------- ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
