Andrea, to follow this up - I followed your advice about keeping the
process stateless, and using SLD env variables to provide the output image
parameters. After fixing a bug in RenderingProcessFunction, and fully
understanding how annotation-driven rendering processes work - everything
works perfectly.
Will be committing a patch for this shortly.
On Thu, Mar 1, 2012 at 10:19 AM, Andrea Aime
<[email protected]>wrote:
> 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 :-)
>
> --
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
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
