September 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-123) Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification

by Richard Hightower (JIRA)

Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification ----------------------------------------------------------------------------------------------------------------------------- Key: CDI-123 URL: https://issues.jboss.org/browse/CDI-123 Project: CDI Specification Issues Issue Type: Feature Request Components: Concepts Affects Versions: 1.1 (Proposed) Reporter: Richard Hightower Fix For: 1.1 (Proposed) Using Seam's CDI XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification. Annotations and Alternatives should always be the first line of offense for doing injection, decoration and interception. However, there are times when you want to configure things that don't fit well into this model. This is also useful for testing. This is not to give up type safeness via annotations, but to have some additional flexibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

8
12
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] 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-203) Decorator support for @MessageDriven bean MessageListener interface

by David Blevins (Created) (JIRA)

Decorator support for @MessageDriven bean MessageListener interface ------------------------------------------------------------------- Key: CDI-203 URL: https://issues.jboss.org/browse/CDI-203 Project: CDI Specification Issues Issue Type: Feature Request Components: Decorators, Java EE integration Affects Versions: 1.1 (Proposed) Reporter: David Blevins Interceptors message-driven beans are explicitly mentioned as supported in CDI 1.0, but decorator support appears to be clearly left out. Decorators that implement the message listener interface would be very useful. As well, most contains have one stack now that does both interceptors and decorators, so enabling this for MDBs would be quite easy. -- 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

4
12
0 / 0

[JBoss JIRA] (CDI-186) Interceptor bindings need clarification

by Jozef Hartinger (Created) (JIRA)

Interceptor bindings need clarification --------------------------------------- Key: CDI-186 URL: https://issues.jboss.org/browse/CDI-186 Project: CDI Specification Issues Issue Type: Clarification Components: Interceptors Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1.EDR2 As part of CDI-2, changes were made to the Interceptors chapter of the CDI specification. These changes need further clarification: {quote} Interceptor bindings defined on methods may override the interceptor bindings defined on classes. {quote} One way to interpret this is that the set of interceptor bindings defined on a method overrides the set of interceptor bindings defined on a class, which is clearly not the intended behavior. {quote} If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the bean or interceptor must override the *inherited set* by definining an annotation instance of its own, otherwise, the container automatically detects the problem and treats it as a definition error. {quote} Here again I would avoid referencing "the inherited set", since it's not clear what that means, and rather use wording similar to the section 2.4.4 - default scope of a stereotype. -- 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
7
0 / 0

[JBoss JIRA] Created: (CDI-127) Add support for annotation scanning of Java enums

by Brian Leathem (JIRA)

Add support for annotation scanning of Java enums ------------------------------------------------- Key: CDI-127 URL: https://issues.jboss.org/browse/CDI-127 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Brian Leathem It would be useful if Java enums were included in the CDI annotation scan. A use case for this is found in the Seam Faces project, where we would like to use annotations on enums for configuration purposes. The annotation would look like: @ViewConfig public enum Pages { ... } It is my understanding that the current CDI specification (1.0) does not require scanning of the enum and will not pick up the @ViewConfig annotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
12
0 / 0

[JBoss JIRA] (CDI-269) Fire ProcessAnnotatedType for annotations

by Pete Muir (JIRA)

Pete Muir created CDI-269: ----------------------------- Summary: Fire ProcessAnnotatedType for annotations Key: CDI-269 URL: https://issues.jboss.org/browse/CDI-269 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.EDR Reporter: Pete Muir Assignee: Pete Muir Fix For: 1.1 (Proposed) If we fire a PAT event for annotations, the members can have @Nonbinding added -- 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
2
0 / 0

[JBoss JIRA] (CDI-243) Consider built-in InjectionPoint not available for stateless session beans

by Martin Kouba (JIRA)

Martin Kouba created CDI-243: -------------------------------- Summary: Consider built-in InjectionPoint not available for stateless session beans Key: CDI-243 URL: https://issues.jboss.org/browse/CDI-243 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Right now it should be possible to inject InjectionPoint metadata to dependent SLSB (see 5.5.7. Injection point metadata). I think it may lead to inconsistencies - SLSB should not have any state as it is usually pooled and reused for every invocation. -- 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
9
0 / 0

[JBoss JIRA] (CDI-173) Improve javadoc for event-firing methods

by Jozef Hartinger (Created) (JIRA)

Improve javadoc for event-firing methods ---------------------------------------- Key: CDI-173 URL: https://issues.jboss.org/browse/CDI-173 Project: CDI Specification Issues Issue Type: Feature Request Components: Javadoc and API Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) The spec says {quote}Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called. The BeanManager.fireEvent() or Event.fire() method rethrows the exception. If the exception is a checked exception, it is wrapped and rethrown as an (unchecked) ObserverException.{quote} The JavaDoc for BM.fireEvent() and Event.fire() only mentions IllegalArgumentException. The fact that the ObserverException or any other unchecked exception raised by an observer method should be mentioned. -- 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, 5 months

4
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012