August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-99. -------------------------- Resolution: Done Marking as done, as we don't know why it was reopened. > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-136) Assumption all @Stateful beans should be passivation capable

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger reassigned CDI-136: ----------------------------------- Assignee: Pete Muir (was: Jozef Hartinger) Looks good to me > Assumption all @Stateful beans should be passivation capable > ------------------------------------------------------------ > > Key: CDI-136 > URL: https://issues.jboss.org/browse/CDI-136 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Java EE integration > Affects Versions: 1.0, 1.1.EDR1 > Reporter: David Blevins > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > > Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope. > Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix. > Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified. > The user should be able to say if they want passivation validation on their stateful bean and dependencies. > We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation. > From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts. -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-99: ------------------------------------ Sorry Pete, I have no idea what I meant by "ambiguous" back then. > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- 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

11 years, 9 months

1
0
0 / 0

CDI 1.1 weekly meeting

by pmuir＠redhat.com

The following is a new meeting request: Subject: CDI 1.1 weekly meeting Organiser: Peter Muir <pmuir(a)redhat.com> Time: 16:00:00 GMT+00:00 - 18:00:00 GMT+00:00 Recurrence: Every Monday. No end date. Effective Aug 20, 2012. Invitees: Mike Brock <cbrock(a)redhat.com>, Joseph Bergmark/Durham/IBM <bergmark(a)us.ibm.com>, "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org> *~*~*~*~*~*~*~*~*~* Weekly CDI 1.1 meeting http://www.timeanddate.com/worldclock/converted.html?iso=20120803T15&p1=0... We will try to use Google Hangout, join #jsr346 10 minutes before the meeting to request an invite. Otherwise switch to the phone teleconference, see https://docs.google.com/spreadsheet/pub?key=0ApqHbXzB1R1gdGRFWXB4TVpNeWFJ... for details.

11 years, 9 months

2
1
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: ------------------------------ The proposal is that this should be a class level annotation, possibly called @HandlesTypes to match Servlet. > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 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: ------------------------------ Stuart is thinking about whether this is only applied to PAT > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 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 edited comment on CDI-43 at 8/17/12 11:21 AM: -------------------------------------------------------- Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} Note that the annotation could appear anywhere on the class that the extension is interested in. This annotation should be @Retention(CLASS), so that it *is* available to libraries that directly read the bytecode but *isn't* available to the JVM to cause potential classloading issues. This means that, for extensions that use this annotation, there is no need to fully load the class for every bean, and instead only load classes that the extension expresses an interest in (discovered by scanning the bytecode rather than via reflection). Note that if even one extension doesn't use this feature, the performance benefit is lost. was (Author: pmuir): Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} Note that the annotation could appear anywhere on the class that the extension is interested in. This annotation should be @Retention(CLASS), so that it *is* available to libraries that directly read the bytecode but *isn't* available to the JVM to cause potential classloading issues. This means that, for extensions that use this annotation, there is no need to fully load the class for every bean, and instead only load classes that the extension expresses an interest in. > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 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 edited comment on CDI-43 at 8/17/12 11:18 AM: -------------------------------------------------------- Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} Note that the annotation could appear anywhere on the class that the extension is interested in. This annotation should be @Retention(CLASS), so that it *is* available to libraries that directly read the bytecode but *isn't* available to the JVM to cause potential classloading issues. This means that, for extensions that use this annotation, there is no need to fully load the class for every bean, and instead only load classes that the extension expresses an interest in. was (Author: pmuir): Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} Note that the annotation could appear anywhere on the class that the extension is interested in. > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 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 edited comment on CDI-43 at 8/17/12 11:07 AM: -------------------------------------------------------- Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} Note that the annotation could appear anywhere on the class that the extension is interested in. was (Author: pmuir): Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 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: ------------------------------ Stuart proposes adding something http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/HandlesTypes... {quote} If an implementation of ServletContainerInitializer specifies this annotation, the Servlet container must pass the Set of application classes that extend, implement, or have been annotated with the class types listed by this annotation to the ServletContainerInitializer.onStartup(java.util.Set>, javax.servlet.ServletContext) method of the ServletContainerInitializer (if no matching classes are found, null must be passed instead) {quote} > 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 > 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012