June 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Closed: (CDI-28) Abstract methods on decorators

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-28?page=com.atlassian.jira.plugin.sys... ] Pete Muir closed CDI-28. ------------------------ Resolution: Done > Abstract methods on decorators > ------------------------------ > > Key: CDI-28 > URL: https://issues.jboss.org/browse/CDI-28 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Confirmed) > > > If a method is abstract: > * if it is a method of a decorated type, it has a generated implementation that calls the delegate > * otherwise, definition error -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-136: -------------------------- Component/s: Beans Java EE integration > 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 > Reporter: David Blevins > Fix For: 1.1 (Proposed) > > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (CDI-128) We need a CDIInvocationContext which provides a getAnnotated

by Richard Hightower (JIRA)

We need a CDIInvocationContext which provides a getAnnotated ------------------------------------------------------------ Key: CDI-128 URL: https://issues.jboss.org/browse/CDI-128 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Richard Hightower The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
4
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-136: -------------------------- Fix Version/s: 1.1 (Proposed) Affects Version/s: 1.0 > 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 > Affects Versions: 1.0 > Reporter: David Blevins > Fix For: 1.1 (Proposed) > > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] Pete Muir moved CDITCK-218 to CDI-136: -------------------------------------- Project: CDI Specification Issues (was: CDI TCK) Key: CDI-136 (was: CDITCK-218) Issue Type: Bug (was: CTS Challenge) Workflow: GIT Pull Request workflow (was: jira) Security: (was: Public) > 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 > Reporter: David Blevins > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-27) Support declarative transactions on managed beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-27: ------------------------------ It's more likely that this will be provided by the EJB spec than by CDI. However as it's a crossover issue, and important for CDI users, it's registered here as a placeholder as well. > Support declarative transactions on managed beans > ------------------------------------------------- > > Key: CDI-27 > URL: https://issues.jboss.org/browse/CDI-27 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

LifeCycle Event Callbacks and Interceptors

by Jens Schumann

Hi all! Recently I have noticed that OWB does not apply (class/method) interceptors to lifecycle event callback methods. I 've chatted with Mark and he referred me to the list. He tried to remember his research on this topic and made the point that class interceptors should probably be applied. However he has the feeling that pure method interceptors may not be applied for lifecycle event callback methods since those methods are no business methods. It seems that neither the CDI spec nor the interceptor spec covers the topic for all variations. After reading the interceptor spec again (chapter "Interceptors for LifeCycle Event Callbacks") I would follow Marks assertions. What do you think? Is there anything missing within the CDI spec (and OWB of course)? Jens

12 years, 10 months

3
3
0 / 0

[JBoss JIRA] Commented: (CDI-27) Support declarative transactions on managed beans

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-27: ---------------------------------- > You could easily re-implement EJB 3.1 transactions with CDI 1.0. a) yes, IF we like to provide such a mechanism in the CDI spec itself, then we definitely should reuse the annotations from the EJB spec as far as possible. b) there are already working portable Extensions which emulate EJB behaviour via CDI interceptors. So I see no real reason why this should be put into the CDI spec. c) the implicit 'TransactionalScope' which internally exists in all EJB containers for 'Transactional EntityManagers' would need a 2 way integration because you can only create an Extended EntityManager via public APIs. Which means this is pretty much EJB container specific. It just feels more natural to me if those EJB containers would provide CDI interceptors for 'extending' the EJB Transaction mechanism to CDI beans also. > Support declarative transactions on managed beans > ------------------------------------------------- > > Key: CDI-27 > URL: https://issues.jboss.org/browse/CDI-27 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-27) Support declarative transactions on managed beans

by Adam Bien (JIRA)

[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ] Adam Bien commented on CDI-27: ------------------------------ > This was not my intention. I'd rather see the CDI spec just providing the basic mechanisms to make such an Interceptor possible (which it already does). But I'd not specify such complex and history-bloated things in the CDI spec itself, but maybe in the EJB spec? Could you please clarify? If you do not intend to introduce an additional annotation, then I'm o.k. with that. You could easily re-implement EJB 3.1 transactions with CDI 1.0. > Support declarative transactions on managed beans > ------------------------------------------------- > > Key: CDI-27 > URL: https://issues.jboss.org/browse/CDI-27 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-27) Support declarative transactions on managed beans

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-27: ---------------------------------- This was not my intention. I'd rather see the CDI spec just providing the basic mechanisms to make such an Interceptor possible (which it already does). But I'd not specify such complex and history-bloated things in the CDI spec itself, but maybe in the EJB spec? > Support declarative transactions on managed beans > ------------------------------------------------- > > Key: CDI-27 > URL: https://issues.jboss.org/browse/CDI-27 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2011