The traversal itself is ok but how do you analyze the expression? I think you have to do it for every component and every value attribute. Thats something i would like to avoid.
2016-04-09 9:38 GMT+02:00 Christian Beikov <[email protected]>: > Hello Thomas, > > well scanning the tree shouldn't be such a big problem I guess since the > JSF lifecycle already traverses the tree multiple times. Doing it another > time shouldn't do that much damage I think, especially because the > traversal would be aware of the client ids that should be rendered in an > ajax request. I also think that it is fairly easy to optimize since I could > cache the preloadable EL-Expressions along with the client ids that they > belong to for a view. So this would only require a traversal once. > > The whole idea and use case for which I am implementing this was to make > the preloading in an automatic fashion without the need to touch the views. > Having a preload tag would be definitely another way, but I would like to > first test the performance impact of scanning the expressions. The preload > tag would also be problematic in the ajax use case since it will probably > be located outside of the components that are rendered. > > I was also thinking about collecting statistics for the methods that are > used and try to start preloading opportunistically based on that data. > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 09.04.2016 um 09:18 schrieb Thomas Andraschko: > >> Hi Christian, >> >> basically thats an interesting idea, just not sure if we could implement >> it >> in a nicer way. >> I think scanning the component tree and analyzing every EL expression >> feels >> a little risky and slow. >> >> Using a bytecode library isn't the problem in the JSF module, we already >> use there our proxy module. >> >> Couldn't we just reuse our @Futureable? >> Sure, the handling in the UI would be little bit different (supplierNames >> vs supplierNames.get()) but Future should work, right? >> >> Regards, >> Thomas >> >> >> >> 2016-04-09 8:06 GMT+02:00 Christian Beikov <[email protected]>: >> >> Hello, >>> >>> I am implementing some POCs for parallel preloading of named producer >>> methods and think I have a working prototype. >>> I wanted to know if you are interested in including this into Deltaspike >>> and if so, how I should contribute it. >>> >>> It is separated into two parts, one is the context capturing in one >>> thread >>> and the possibility to start these contexts for a new thread. >>> The other part is a phase listener that scans the component tree for >>> UEL-Expressions that evaluate to a named producer method which is >>> annotated >>> with a special interceptor annotation(@PreloadingSafe). These producers >>> are >>> then invoked in the before render response phase in parallel. This >>> currently works by creating a proxy from the returned interface. The >>> invocation handler behind it, just delegates to the result of the future >>> that was received by submitting the producer method to an >>> ExecutorService. >>> It would be nice if this could also work with non-interface types but >>> that >>> would require some bytecode library which I didn't want to introduce yet. >>> >>> Here some example code: >>> >>> public class SomeProducerBean { >>> >>> @PreloadingSafe >>> @Named >>> @Produces >>> @RequestScoped >>> public List<String> getSupplierNames() { /* Some DB call */ } >>> >>> } >>> >>> <html> >>> ... >>> <ui:repeat value="#{supplierNames}" var="supplName"> >>> #{supplName} >>> <ui:repeat> >>> ... >>> </html> >>> >>> So the rendering until it reaches the ui:repeat runs in parallel to the >>> preloading of the supplier names. When the JSF-Component tries the >>> evaluate >>> the expression it might need to block. Also note that other expressions >>> will still be evaluated in parallel even if one blocks so this can be a >>> huge boost for performance. >>> >>> It's not fully tested yet. The easy case works but I haven't tested more >>> complex scenarios or possible threading issues yet. >>> >>> What do you say? >>> >>> -- >>> >>> Mit freundlichen Grüßen, >>> ------------------------------------------------------------------------ >>> *Christian Beikov* >>> >>> >
