Caused by: javax.enterprise.inject.AmbiguousResolutionException: There is more than one Bean with type javax.enterprise.context.ConversationQualifiers: [@javax.enterprise.inject.Default()] for injection into Field Injection Point, field name : conversation, Bean Owner : [ConversationAliaser, WebBeansType:MANAGED, Name:null, API Types:[eg.ConversationAliaser,java.lang.Object], Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]] found beans: Conversation, WebBeansType:PRODUCERMETHOD, Name:conversation, API Types:[javax.enterprise.context.Conversation,java.lang.Object], Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any,javax.inject.Named] from file:/D:/development/workspaces/openejb-el/target/test-classes/eg/ConversationWrapper.class ConversationImpl, WebBeansType:CONVERSATION, Name:javax.enterprise.context.conversation, API Types:[org.apache.webbeans.conversation.ConversationImpl,javax.enterprise.context.Conversation,java.lang.Object], Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any] from jar:file:/C:/Users/xavier/.m2/repository/org/apache/openwebbeans/openwebbeans-impl/1.6.3/openwebbeans-impl-1.6.3.jar!/org/apache/webbeans/conversation/ConversationImpl.class
From: Mark Struberg <[email protected]> Sent: Wednesday, September 28, 2016 11:20 PM To: [email protected] Subject: Re: OpenEJB and EL +1 means @RequestScoped public class ConversationWrapper { private @Inject Conversation conv; @Produces @Dependent @Named("conv") public Conversation getConv() { return conv; } } On Wednesday, 28 September 2016, 23:10, Romain Manni-Bucau <[email protected]> wrote: > > >a producer allows to get a shorter/more elegant naming like #{conv.id} if you >@Produces @Named("conv") ;) > > > >Romain Manni-Bucau >@rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | >JavaEE Factory > >2016-09-28 23:01 GMT+02:00 Mark Struberg <[email protected]>: > >Oh boy, sorry for you. You did hit a blank spot in the CDI spec. >> >>Problem is that the EE umbrella spec, the EL spec and the CDI spec contradict >>each other. >> >>The Weld guys solved this by introducing a Javax class. But that takes away >>the whole javax.* tree for the EL. That's just not good as it contradicts the >>EL spec. >> >>Could you please try the following >> >>@RequestScoped >>@Named("conversation") >>public class ConversationWrapper { >> private @Inject Conversation conv; >> >> public Conversation get() { >> return conv; >> } >>} >> >>And in the EL just use #{conversation.get.id} >> >>LieGrue, >>strub >> >> >> >> >> >>> On Wednesday, 28 September 2016, 22:12, Xavier Dury <[email protected]> >>> wrote: >>> > I really don't understand how something like <f:param >>> name="cid" >>> value="#{javax.enterprise. context.conversation.id}"/> actually >>> works... something must be made to make the EL processor accept that invalid >>> bean name. >>> >>> Making a producer which @Produces @Named Conversation conflicts with the >>> built-in bean from OWB (with WebBeanType.CONVERSATION)... >>> >>> ... so, I have done the following for my tests but I feel a bit ashamed >>> because >>> I can't imagine there is no better solution than this ;-) >>> >>> public class ConversationAliaser { >>> public class Javax { >>> public Enterprise getEnterprise() {return new Enterprise();} >>> >>> } >>> public class Enterprise { >>> public Context getContext() {return new Context();} >>> } >>> public class Context { >>> public Conversation getConversation() {return conversation;} >>> >>> } >>> @Inject >>> private Conversation conversation; >>> @Produces @ApplicationScoped @Named("javax") >>> public Javax javax() {return new Javax();} >>> } >>> >>> But that works! >>> >>> Xavier >>> >>> >>> >>> From: Xavier Dury <[email protected]> >>> Sent: Wednesday, September 28, 2016 8:42 PM >>> To: [email protected] >>> Subject: Re: OpenEJB and EL >>> >>> Hmmm... I guess I'll have to @Produces @Named the conversation if I want to >>> use it in ELs. I don't know if something like >>> #{applicationScope['javax. enterprise.context. conversation'].transient} >>> would work? >>> >>> I remember back in my JSP days that, sometimes, I had to use something like >>> ${requestScope['javax.servlet. forward.request_uri']} instead of >>> plain ${javax.servlet.forward. request_uri}. >>> >>> Xavier >>> >>> >>> From: Romain Manni-Bucau <[email protected]> >>> Sent: Wednesday, September 28, 2016 6:54 PM >>> To: [email protected] >>> Subject: Re: OpenEJB and EL >>> >>> hmm, wonder if it is linked to the value you try to evaluate (which doesn't >>> respect EL spec even if in CDI spec - don't ask please ;)).. See >>> https://issues.jboss.org/ browse/CDITCK-462 / System Dashboard - JBoss Issue Tracker issues.jboss.org Atlassian JIRA Project Management Software (v6.4.11#64026-sha1:78f6ec4) About JIRA; Report a problem; Powered by a free Atlassian JIRA open source license for Red Hat ... >>> http://lists.jboss.org/ pipermail/cdi-dev/2015- January/006009.html lists.jboss.org Mailing Lists lists.jboss.org lists.jboss.org Mailing Lists: Welcome! Below is a listing of all the public mailing lists on lists.jboss.org. Click on a list name to get more information ... >>> >>> >>> >>> >>> 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 ... >>> <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-28 18:17 GMT+02:00 Xavier Dury <[email protected]>: >>> >>>> Hi Romain, >>>> >>>> I tried with org.apache.tomcat:tomcat- jasper-el:8.5.5 but it does not >>>> parse my expression until I change ".transient" by >>> ".isTransient()" and >>>> then it gives the same error: javax.el. PropertyNotFoundException: >>>> ELResolver cannot handle a null base Object with identifier >>> 'javax'. >>>> >>>> Does the EL context need something else than adding the >>>> BeanManager.getELResolver() to be able to resolve some implicit objects? >>>>I >>>> don't understand why it works with ri-1.0. >>>> >>>> Xavier >>>> >>>> >>>> From: Romain Manni-Bucau <[email protected]> >>>> Sent: Wednesday, September 28, 2016 4:02 PM >>>> To: [email protected] >>>> Subject: Re: OpenEJB and EL >>>> >>>> Hi Xavier >>>> >>>> On the phone so hard to give you a link bit try using tomcat el impl of >>>> tomcat 8.5 >>>> >>>> Le 28 sept. 2016 15:29, "Xavier Dury" <[email protected]> >>> a écrit : >>>> >>>> > Hi, >>>> > >>>> > I am using OpenEJB for my tests and need support for EL expressions in >>> my >>>> > own code. >>>> > >>>> > By default, if I do something like this (pay attention to the >>>> expression): >>>> > >>>> > ExpressionFactory factory = beanManager. wrapExpressionFactory( >>>> > ExpressionFactory.newInstance( )); >>>> > StandardELContext elContext = new StandardELContext(factory); >>>> > elContext.addELResolver( beanManager.getELResolver()); >>>> > ValueExpression expression = factory.createValueExpression( elContext, >>>> > "#{javax.enterprise.context. conversation.transient}", >>> Boolean.class); >>>> > expression.getValue(elContext) ; >>>> > >>>> > and only add org.apache.tomee:openejb-core: 7.0.1 to my project then I >>>> get >>>> > javax.el.ELException: Unable to find ExpressionFactory of type: >>>> > org.apache.el. ExpressionFactoryImpl >>>> > >>>> > if I add org.glassfish:javax.el:3.0.0 then I get javax.el. >>>> PropertyNotFoundException: >>>> > ELResolver cannot handle a null base Object with identifier >>> 'javax' >>>> > >>>> > if I switch the EL library to com.sun.el:el-ri:1.0 (+ >>> META-INF/javax.el. >>>> ExpressionFactory >>>> > < com.sun.el. ExpressionFactoryImpl) then my expression can be >>> evaluated >>>> > but I can't use any new feature of 3.0 (like lambdas) >>>> > >>>> > So, either my dependencies are wrong or I am not correctly >>> initializing >>>> my >>>> > factory. >>>> > >>>> > Does anybody have an idea? >>>> > >>>> > Thanks, >>>> > >>>> > Xavier >>>> >>>> >>> >> > > >
