On Wed, Feb 29, 2012 at 11:31 PM, Andrea Aime
<[email protected]>wrote:
> On Wed, Feb 29, 2012 at 11:33 PM, Martin Davis <[email protected]> wrote:
> >> A stateful transformation is dangeours business, as you have just one
> >> instantiated,
> >> ever (styles are cached, and so is whatever is inside of them),
> >> and it serves all concurrent requests for all possible requests, maybe
> >> for different
> >> maps or with different parameters.
> >
> >
> > Hmmm... do you mean there is a single copy of the process object shared
> > across all styles which reference that process? Or is there a separate
> one
> > created for each style which uses it? If the former, then yes, I have a
> > problem!
>
> Hmm... good question... I had to look it up in the code.
> So, process factories are free to instantiate a process multiple times,
> each time create(Name) is called, but the Spring based one will
> end up calling:
> return applicationContext.getBean(beanName);
>
> which means Spring will return the actual process bean, and that normally
> means it's a singleton, unless you declared otherwise in the application
> context.
>
> However rendering transformations are filter functions, wrappers around
> processes, created by the ProcessFunctionFactory.. and as far as I can
> see there too you get the on the fly creation of the process.
>
> That said, styles are cached and they refer to the filter function wrapping
> the process directly, which means each style has its own private
> rendering transform, but that one is long lived, that is, all requests
> hitting
> that style will share the same function instance and thus the same process.
>
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...)
>
> > 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).
In the short term I will try and re-implement as a raw Process, and see if
I get the invertQuery args correctly. In the long term it would be nice to
get that bug fixed, since anno-driven processes are much nicer to write
(and read!)
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?
--
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
