October 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-43: -------------------------------- Keeping open until the WithAnnotation value member type is handled. Feel free to close if you track this requirement elsewhere. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Labels: FAQ > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-43. -------------------------- Labels: FAQ (was: ) Resolution: Done > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Labels: FAQ > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-43: ------------------------------ Overriding - this seems correct behavior to me. Modification - I was expecting us to take option (1). This seems like an FAQ to me. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Labels: FAQ > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

Re: [cdi-dev] Adding portlet support to CDI, first draft for review

by Pete Muir

On 11 Sep 2012, at 21:08, Neil Griffin wrote: > Comments inline, with one question for Pete inline as well. > > On Sep 11, 2012, at 8:14 AM, Pete Muir <pmuir(a)redhat.com> wrote: > >> >> On 10 Sep 2012, at 19:58, Julien Viet wrote: >> >>> Hi, >>> >>> I think that one important issue around this is the fact that Portlet was never part of Java EE. Back in Portlet 2.0 time, Stefan (the IBM spec lead) discussed with the Java EE (or J2EE rather) spec lead to work on the inclusion of the portlet container but nothing came out of it. Therefore the portlet spec defines a component model for aggregated application, it is designed to interact with the Servlet specification but it does not have a formal relationship with Jave EE. >> >> Agreed, this was an issue that should have added as an open issue. > > Perhaps one way around the Java-EE issue, would be to have the CDI Spec define requirements for portlet support, but to have it be an "optional" feature for vendors to implement. Portlet support would then be a value-add for Weld. We don't really do this in the CDI spec today, and the spec is not organised in this way. i.e. Major PITA ;-) > >>> On Sep 7, 2012, at 8:56 PM, Pete Muir <pmuir(a)redhat.com> wrote: >>> >>>> All, >>>> >>>> I've drafted up the first round of changes. The diff is at https://github.com/pmuir/cdi/compare/CDI-120 and I've attached a copy of the spec. Please use them in tandem to understand the changes I've made, if you don't read docbook ;-) >>>> >>>> <cdi-spec.pdf> >>>> >>>> I've added a few open issues: >>>> >>>> OPEN ISSUE: Should we support injection into portlets and portlet filters? <-- My understanding is we can't do this without portlet spec changes, but please comment >>> >>> I believe we should, I don't think we need portlet spec changes (I initially said we should but it is a mistake, please apologize). >> >> Ok, let's think about how we specify this. CDI automatically injects "beans" (which it defines) and "Java EE component classes" (which the Java EE spec defines, which includes Servlets, filters, EJBs etc - i.e. all the Java EE non-CDI artifacts you get injection into today). > > The portlet container acts as a pseudo-IOC container for managing Singleton instances of Portlet and PortletFilter, as defined by portlet developers in the WEB-INF/portlet.xml descriptor. > > @Pete: Is it possible for a CDI implementation like Weld would be able to @Inject into instances that it is not managing? It is, yes. It's just a case of what we spec vs what is vendor value-add. > If not, then I have an idea for an alternate mechanism. > >> >>> >>>> OPEN ISSUE: Where should we specify JSF Portlet Bridge specific rules about propagating the request context between the action request and render requests? <-- Ken and I propose these go into the bridge spec >>> >>> In Portlet Container, request and action phases are clearly separated and one should not assume that anything associated with a request could be propagated to other phases. Usually web framework (built on top of servlet) don't do that unless they implement the "redirect-after-post" scheme which would break the request into two phases (action -> redirect -> render). >>> >>> The component in charge of coordinating portlet phases is the portal and this part is not specified, so some portal can perform the two phases in a single request and some can do in two requests. >>> >>> Technically speaking, I think the main issue is that you never have the guarantee that the render phase will be invoked after the action phase whether it's managed by the Portlet Container / Portal or by JSF Portlet Bridge. If you have a solution for propagating the request context between the phases that works if the render phase is not invoked, then it could even be managed by the Portlet Container. >>> >>> The benefit of putting in the Portlet Container is that it would benefit all frameworks for Portlets and would not be restricted to the Portlet Bridge. >> >> I'll let Neil, Mike and Ken comment here on what the Portlet Bridge does today (it's possible I've misunderstood what they told me). > > Although it is not guaranteed, I think that it is safe for CDI to assume that the RENDER_PHASE of the portlet lifecycle will be invoked 99.999% of the time after the ACTION_PHASE. As a failsafe, there could be a cleanup mechanism upon session expiration. > > The requirement for propagating the request context between the action request and render requests is something that JSF portlets require, and is currently specified in the JSF Portlet Bridge spec via propagation of request attributes. Although it would be nice to have in the Portlet API, it is not always required by plain old Java/JSP portlets. > > In order to foster adoption, I think that this is something that Oracle, JBoss, and Liferay could support directly in our JSF Portlet Bridge implementations, which could later be formalized by the next JSF Portlet Bridge EG. This is the strategy we all adopted for JSF 2.0 support. The idea is to spec this behavior for CDI in the PortletBridge spec anyway, so this seems sane. > >> >>> >>>> OPEN ISSUE: Where should we specify JSF Portlet Bridge specific rules about propagating transient conversations between the action request and render requests? <-- Ken and I propose these go into the bridge spec >>> >>> Same as above :-) > > With this one too, I'd say let's get it working in our bridge implementations, and later formalize by the next JSF Portlet Bridge EG. > >>> >>>> >>>> In your review, please do focus on whether I've used terminology aligned with the portlet spec, so that we don't end up with ambiguity! >>>> >>>> Thanks! >>>> >>>> Pete >>>> >>> >> >

12 years, 4 months

3
14
0 / 0

[JBoss JIRA] (CDI-39) Add a standard format for defining metadata about extensions

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-39?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-39: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) Defer. > Add a standard format for defining metadata about extensions > ------------------------------------------------------------ > > Key: CDI-39 > URL: https://issues.jboss.org/browse/CDI-39 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > Build on the support introduced for Manifests in CDI-163 and specify some standard keys: > * id > * description > * version > Add a non-normative note that an impl may wish to use this information and log what extensions are present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (CDI-120) Add an optional Portlet specification support

by Mark Struberg (JIRA)

Add an optional Portlet specification support --------------------------------------------- Key: CDI-120 URL: https://issues.jboss.org/browse/CDI-120 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Reporter: Mark Struberg We should mention the portlet specification and how CDI-1.1 should be utilised/supported in a portlet environment. This is an important prerequisite for the JSR-344 EG to deprecate the JSF @javax.faces.bean.ManagedBean capabilities. Imo there is currently no argument which prevents to run a CDI container from running in a portlet environment anyway. No CDI interface imports any javax.servlet.* class. It could affect the wording in 6.5.2. which defines the built in scopes as being 'as defined in the Servlet specification'. We could easily extend this to also cover the portlet definition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
8
0 / 0

[JBoss JIRA] (CDI-254) Add a BeanManager.qualiferEquals() utility method

by Pete Muir (JIRA)

Pete Muir created CDI-254: ----------------------------- Summary: Add a BeanManager.qualiferEquals() utility method Key: CDI-254 URL: https://issues.jboss.org/browse/CDI-254 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) Manually implement qualifier equality is quite hard to do correctly and efficiently. Expose a utility method to do this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
8
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-83. -------------------------- Resolution: Done > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-58. -------------------------- Resolution: Done > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PRD > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated types'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-89) Add @Unwraps from Seam Solder

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-89?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-89: ------------------------------ I;'m going to leave this open, but defer it for now, as we don't quite have support for a pull based state management yet (right now, something needs to evict the current state). > Add @Unwraps from Seam Solder > ------------------------------ > > Key: CDI-89 > URL: https://issues.jboss.org/browse/CDI-89 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: TBD > > > @Unwraps allows for an essentially stateless scope for producer methods and fields. > At injection time a dependent scoped proxy is injected into the injection point. When a methods is invoked on this proxy it calls the corresponding @Unwraps methods to get the instance to invoke the method on. > Because the proxy is @Dependent scoped, the @Unwraps method can inject the corresponding InjectionPoint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2012