Handling by buckets creates an effort of around O(n^2) :( EL is already slow due to the tons of empty iterations. Any additonal work would hurt badly.
LieGrue, strub > Am 29.09.2016 um 20:21 schrieb Romain Manni-Bucau <[email protected]>: > > well best would probably be to: > > a. allow to escape dots > b. allow to resolve by bucket (if javax doesnt exist try javax.enterprise > etc...) > c. give a beans handler in CDI > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2016-09-29 20:20 GMT+02:00 Xavier Dury <[email protected]>: > >> Well, replace JspResolver by ServletResolver in my previous message... >> >> >> >> >> From: Xavier Dury <[email protected]> >> Sent: Thursday, September 29, 2016 8:18 PM >> To: [email protected] >> Subject: Re: OpenEJB and EL >> >> Indeed, el resolvers should then be splitted like this: >> >> - JspResolver >> - CdiResolver >> - JavaxResolver // must always come last, greedily constructs the chain of >> identifiers starting with 'javax' >> >> [JspResovler] >> public Object getValue(ELContext context, Object base, Object property) { >> if (base instanceof ExpandingImplicitObject) { >> ExpandingImplicitObject implicit = >> (ExpandingImplicitObject) base; >> if ("javax.servlet.forward".equals(implicit.getName())) { >> if ("query_string".equals(property)) { >> // return query string >> } >> if ("context_path".equals(property)) { >> // return context path >> } >> ... >> } >> if ("javax.servlet.include".equals(implicit.getName())) { >> if ("query_string".equals(property)) { >> // return query string >> } >> if ("context_path".equals(property)) { >> // return context path >> } >> ... >> } >> } >> return null; >> } >> >> [CdiResolver] >> public Object getValue(ELContext context, Object base, Object property) { >> if (base instanceof ExpandingImplicitObject) { >> ExpandingImplicitObject implicit = >> (ExpandingImplicitObject) base; >> if ("javax.enterprise.context".equals(implicit.getName()) >> && "conversation".equals(property)) { >> // return conversation >> } >> } >> return null; >> } >> >> [JavaxResolver] >> public Object getValue(ELContext context, Object base, Object property) { >> if (base == null && "javax".equals(property)) { >> context.setPropertyResolved(base, property); >> return new ExpandingImplicitObject("javax"); >> } >> if (base instanceof ExpandingImplicitObject && property instanceof >> String) { >> context.setPropertyResolved(base, property); >> return ((ExpandingImplicitObject) base).expand((String) >> property); >> } >> return null; >> } >> >> This could be totally portable on one condition: that the identifier chain >> (or whatever you cant to call it, ExpandingImplicitObject in my example) >> class be shared in a common module between Jsp and Cdi (el-api?) >> >> >> >> >> >> >> From: Mark Struberg <[email protected]> >> Sent: Thursday, September 29, 2016 5:18 PM >> To: [email protected] >> Subject: Re: OpenEJB and EL >> >> The problems are in the details. >> >> an EL #{javax.enterprise.context.conversation.id} >> will iterate over the EL loader chain a whooping 5 times! >> >> First it will resolve „javax“. Then on that object it will resolve >> „enterprise“, then … >> And on the last (id) you will finally hit the OWB WebBeansELResolver. >> >> The problem is that you have no way of knowing if after „java“ there will >> be a „servlet“ or an „enterprise“… >> So if you implement this for CDI, then there is no way any other spec can >> implement it. >> >> This would only be possible if there is a single instance for the whole EE >> container. Which is perfectly doable in TomEE - but not in OWB. >> >> LieGrue, >> strub >> >> >>> Am 29.09.2016 um 14:41 schrieb Romain Manni-Bucau <[email protected] >>> : >>> >>> yep, you can add a test on "enterprise" as well. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> >> >> >> Romain Manni-Bucau (@rmannibucau) | Twitter >> twitter.com >> The latest Tweets from Romain Manni-Bucau (@rmannibucau). ASF / Java(EE) / >> Angular. LinkedIn: https://t.co/dX7XMGjbBi. JavaEE Factory: >> https://t.co/0VnvWwbedt . Blog ... >> >> >> >> Romain Manni-Bucau (@rmannibucau) | Twitter >> twitter.com >> The latest Tweets from Romain Manni-Bucau (@rmannibucau). ASF / Java(EE) / >> Angular. LinkedIn: https://t.co/dX7XMGjbBi. JavaEE Factory: >> https://t.co/0VnvWwbedt . Blog ... >>> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >> >> >> RBlog: the RManniBucau v2 Blog >> blog-rmannibucau.rhcloud.com >> RBlog: Romain Manni-Bucau Blog about Java, JavaEE, TomEE, Angular, Open >> Source, Code and geeky topics... >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ >> rmannibucau> | >> >> >> >> [old blog] new RManniBucau().blog() >> rmannibucau.wordpress.com >> New blog on: https://blog-rmannibucau.rhcloud.com/ >> >> >> >> rmannibucau (Romain Manni-Bucau) · GitHub >> github.com >> rmannibucau has 99 repositories available. Follow their code on GitHub. >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> >> >> >> Romain Manni-Bucau | LinkedIn >> www.linkedin.com >> View Romain Manni-Bucau’s professional profile on LinkedIn. LinkedIn is >> the world's largest business network, helping professionals like Romain >> Manni-Bucau discover ... >>> <http://www.tomitribe.com> | JavaEE Factory >>> <https://javaeefactory-rmannibucau.rhcloud.com> >>> >>> 2016-09-29 14:38 GMT+02:00 Xavier Dury <[email protected]>: >>> >>>> something like this? https://gist.github.com/kalgon/ >>>> c1ccffff45540a629314f615b90f944f >>>> >>>> >>>> >> >> >>
