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* >
