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

Reply via email to