[JBoss JIRA] Resolved: (CDI-80) Support conversations in Servlet
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.sys... ]
Pete Muir resolved CDI-80.
--------------------------
Resolution: Done
> Support conversations in Servlet
> --------------------------------
>
> Key: CDI-80
> URL: https://issues.jboss.org/browse/CDI-80
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts, Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> In CDI 1.0, the Conversation Scope has extremely limited availability. It is accessible from after RESTORE_VIEW phase in JSF, to the end of the Response, but this is extremely limiting, and in fact does not even address all use-cases within JSF.
> For instance:
> User has custom PhaseListener for Before RESTORE_VIEW phase, or user has custom PhaseListener that invokes before ConversationPhaseListener.
> In said PhaseListener, user attempts to access a ConversationScoped bean.
> ContextNotActiveException results, even though there may be a valid CID in the Request URL
> Example 2:
> User attempts to access ConversationScope outside of the JSF lifecycle (Via EL in a Servlet or ServletFilter, for instance.)
> ContextNotActiveException results, this just doesn't work!
> There is no reason why the ConversationScope should be any less available than the RequestScope, since both depend on the same underlying context objects. (Request, Session, etc)
> ConversationScope should be ubiquitous in the Servlet Container Request/Response lifecycle. This will greatly improve ability to use CDI in view/web frameworks other than JSF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Resolved: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir resolved CDI-33.
--------------------------
Resolution: Done
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Minor
> Fix For: 1.1 (Confirmed)
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
@New and producer methods/fields
by Mark Struberg
Hi folks!
We recently talked about ways to properly destroy beans which got created via Instance or @New.
I just realized that only having
@Inject @New MyClass dings;
might not be enough.
Imagine you have 2 producer methods which create EntityManagers
public class EntityManagerProducer {
@Produces @RequestScoped @UserDb
public void createUserDbEm() {
return entityManagerFactory.createEntityManager("userdb");
}
@Produces @RequestScoped @AdminDb
public void createAdminDbEm() {
return entityManagerFactory.createEntityManager("admindb");
}
}
If I need a 'temporarily self managed' userdb EntityManager, I cannot just
type
@Inject @New @UserDb EntityManager userDbEm;
because according to the spec there is only 1 Bean with exactly @New (and none with additional @UserDb)
The @New is basically useless for producer methods, isn't?
Do we like to address this somehow?
LieGrie,
strub
12 years, 8 months
[JBoss JIRA] Created: (CDI-168) UOE on AS 7.0.2
by Pete Muir (JIRA)
UOE on AS 7.0.2
---------------
Key: CDI-168
URL: https://issues.jboss.org/browse/CDI-168
Project: CDI Specification Issues
Issue Type: Bug
Reporter: Pete Muir
Stuff still seems to work (maybe just a cache though?)
19:01:28,966 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http--127.0.0.1-8080-5) Exception Processing ErrorPage[errorCode=404, location=/404.jsf]: javax.servlet.ServletException: no transaction
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:134) [rewrite-impl-servlet-1.0.0.Alpha4.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:543) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:528) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:454) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.UnsupportedOperationException: no transaction
at org.jboss.seam.transaction.NoTransaction.begin(NoTransaction.java:47) [seam-persistence-3.0.0.Final.jar:]
at org.jboss.seam.transaction.DefaultSeamTransaction.begin(DefaultSeamTransaction.java:102) [seam-persistence-3.0.0.Final.jar:]
at org.jboss.seam.transaction.Work.workInTransaction(Work.java:51) [seam-persistence-3.0.0.Final.jar:]
at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke(TransactionInterceptor.java:188) [seam-persistence-3.0.0.Final.jar:]
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation.invoke(InterceptorInvocation.java:72) [jboss-interceptor-core-2.0.0.Alpha3.jar:2.0.0.Alpha3]
at org.jboss.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:82) [jboss-interceptor-core-2.0.0.Alpha3.jar:2.0.0.Alpha3]
at org.jboss.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:133) [jboss-interceptor-core-2.0.0.Alpha3.jar:2.0.0.Alpha3]
at org.jboss.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:112) [jboss-interceptor-core-2.0.0.Alpha3.jar:2.0.0.Alpha3]
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:65) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at com.acme.view.-2068363872$Proxy$_$$_WeldSubclass.getItemType(-2068363872$Proxy$_$$_WeldSubclass.java) [classes:]
at com.acme.view.MemberBean$Proxy$_$$_WeldClientProxy.getItemType(MemberBean$Proxy$_$$_WeldClientProxy.java) [classes:]
at org.metawidget.forge.navigation.Navigation.getListItems(Navigation.java:47) [metawidget-forge-scaffold-1.0.0-20110922.190837-19.jar:]
at org.metawidget.forge.navigation.Navigation$Proxy$_$$_WeldClientProxy.getListItems(Navigation$Proxy$_$$_WeldClientProxy.java) [metawidget-forge-scaffold-1.0.0-20110922.190837-19.jar:]
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302) [jboss-el-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at org.apache.el.parser.AstValue.getValue(AstValue.java:134) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:45) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.parser.AstNot.getValue(AstNot.java:42) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:413) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1750) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.ocpsoft.rewrite.faces.RewriteViewHandler.renderView(RewriteViewHandler.java:154) [rewrite-integration-faces-1.0.0.Alpha4.jar:]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
... 19 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
Clarification for manually resolving 'Instance'
by Mark Struberg
Hi!
Currently both Weld and OWB blow up if I resolve an unparameterized 'Instance' object.
beanManager.getBeans(Instance.class);
will return zero beans, so there is no way to call beanManager.getReference ...
Of course with a little trick I was able to get it working in OWB:
Type instanceType = new TypeLiteral<Instance<Object>>(){}.getType();
Set<Bean<?>> beans = beanManager.getBeans(instanceType);
(did not test it on Weld yet)
My question is which behaviour is expected.
This question could maybe be generalized to: how do beans for parameterized types need to get handled?
LieGrue,
strub
12 years, 8 months
[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-18:
----------------------------------
There is a schema for our beans.xml already, aint?
Other specs (see JPA) add new features if they find a version="1.1"
This would be a perfect way to remain compatibility with older beans.xml format projects imo.
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Commented: (CDI-92) Allow injection of Bean object for a bean
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici commented on CDI-92:
-------------------------------------
@Inject @Delegate means something else in the case of a Decorator anyway (and there's no delegate in the case of an interceptor). Also, I cannot see why there cannot be two separate concerns:
a) Inject the bean (which in the case of an Interceptor/Decorator will inject the Interceptor/Decorator itself, they're beans too, nothing wrong with that)
b) Inject the target instance or delegate. Since we don't have a common term for interception or decoration we could have two distinct identifiers:
@Inject @Intercepted Bean<?> bean; for interceptors
@Inject @Decorated Bean<?> bean; for decorators
One point against this would be the proliferation of annotations, but I think that using distinct annotations helps keeping the spec clear.
> Allow injection of Bean object for a bean
> -----------------------------------------
>
> Key: CDI-92
> URL: https://issues.jboss.org/browse/CDI-92
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Issue Comment Edited: (CDI-92) Allow injection of Bean object for a bean
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici edited comment on CDI-92 at 9/20/11 2:14 PM:
--------------------------------------------------------------
@Inject @Delegate means something else in the case of a Decorator anyway (and there's no delegate in the case of an interceptor). Also, I cannot see why there cannot be two separate concerns:
a) Inject the bean (which in the case of an Interceptor/Decorator will inject the Interceptor/Decorator itself, they're beans too, nothing wrong with that)
b) Inject the target instance or delegate. Since we don't have a common term for interception or decoration we could have two distinct qualifiers:
@Inject @Intercepted Bean<?> bean; for interceptors
@Inject @Decorated Bean<?> bean; for decorators
One point against this would be the proliferation of annotations, but I think that using distinct annotations helps keeping the spec clear.
was (Author: marius.bogoevici):
@Inject @Delegate means something else in the case of a Decorator anyway (and there's no delegate in the case of an interceptor). Also, I cannot see why there cannot be two separate concerns:
a) Inject the bean (which in the case of an Interceptor/Decorator will inject the Interceptor/Decorator itself, they're beans too, nothing wrong with that)
b) Inject the target instance or delegate. Since we don't have a common term for interception or decoration we could have two distinct identifiers:
@Inject @Intercepted Bean<?> bean; for interceptors
@Inject @Decorated Bean<?> bean; for decorators
One point against this would be the proliferation of annotations, but I think that using distinct annotations helps keeping the spec clear.
> Allow injection of Bean object for a bean
> -----------------------------------------
>
> Key: CDI-92
> URL: https://issues.jboss.org/browse/CDI-92
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
