What about reusing @Futurable on the producer and create a new tag -
something like "ds:preload value=#{supplierNames}", which be placed early
in the content?2016-04-09 9:18 GMT+02:00 Thomas Andraschko <[email protected]>: > 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* >> > >
