June 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-119) Standard way to obtain a BeanManager regardless of environment

by Cloves Almeida (JIRA)

Standard way to obtain a BeanManager regardless of environment -------------------------------------------------------------- Key: CDI-119 URL: https://issues.jboss.org/browse/CDI-119 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Cloves Almeida Priority: Minor As an alternative to #CDI-117: There should be a standard way to obtain a BeanManager instance regardless of environment. I propose a BeanManagerFactory that would implement the following resolution: 1) if in a JEE environment, use the JNDI resolution already proposed on spec 2) if in a non-JEE servlet container, use the servlet context attribute as proposed in #CDI-117 3) else, fallback on a "singleton" BeanManager For extensability, one could override the resolution mechanism by providing his own BeanManagerResolver. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (CDI-116) Add programmatic API to manipulate XML metadata

by Pete Muir (JIRA)

Add programmatic API to manipulate XML metadata ----------------------------------------------- Key: CDI-116 URL: https://issues.jboss.org/browse/CDI-116 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
5
0 / 0

[JBoss JIRA] Created: (CDI-133) Further clarify the notion of a decorated type

by Marius Bogoevici (JIRA)

Further clarify the notion of a decorated type ---------------------------------------------- Key: CDI-133 URL: https://issues.jboss.org/browse/CDI-133 Project: CDI Specification Issues Issue Type: Clarification Reporter: Marius Bogoevici Priority: Optional Essentially, remove the period between the first and second statement and use a single phrase instead: {quote} The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for <literal>java.io.Serializable</literal>. The decorator bean class and its superclasses are not decorated types of the decorator. {quote} This is a rather cosmetic change, but can improve the readability of the section. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

passivation capable parameters for producerMethods

by Mark Struberg

Hi! Section 6.6.4 declares that: > If a producer method declares a passivating scope and: > .. > * has a parameter that does not resolve to a passivation capable > dependency, > then the container automatically detects the problem and > treats it as a deployment problem. What is the reason for this restriction? Something like @Produces @SessionScoped @AutoAuthenticated public User getCurrentUser(EntityManager em) { return ... (EntityManager gets produced as @RequestScoped) would not be allowed because EntityManager is not Serializable. txs and LieGrue, strub

13 years, 5 months

3
10
0 / 0

[JBoss JIRA] Created: (CDI-107) Provide automatic startup capabilities for beans.

by John Ament (JIRA)

Provide automatic startup capabilities for beans. ------------------------------------------------- Key: CDI-107 URL: https://issues.jboss.org/browse/CDI-107 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Certain beans (such as @ApplicationScoped or @Singleton) should be able to be instantiated on startup of the application automatically, similar to EJB3.1's @Startup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Commented: (CDI-86) Support firing general purpose lifecycle events in Java EE environments

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-86?page=com.atlassian.jira.plugin.sys... ] John Ament commented on CDI-86: ------------------------------- Recommending CDI-107 as a duplicate of this as well. It's essentially what I was asking for. > Support firing general purpose lifecycle events in Java EE environments > ----------------------------------------------------------------------- > > Key: CDI-86 > URL: https://issues.jboss.org/browse/CDI-86 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: 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

13 years, 6 months

1
0
0 / 0

CDI-136: Validation of passivation capability for SFSBs

by Pete Muir

All, David Blevins raised this issue https://issues.jboss.org/browse/CDI-136 about CDI overstepping the it's responsibilities and validating that every SFSB must be passivation capable, not just those that belong to passivation capable scopes in CDI. I would assume this check was introduced because of a misinterpretation of the EJB spec that *all* SFSBs are passivation capable, not just some. Speaking to David, he has indicated this is certainly not the case. In this case, I think CDI is being somewhat presumptious and should validate only the beans that it needs to (those that belong to passivation capable scopes in CDI). EJB does not offer up any metadata about whether a SFSB is passivation capable, so I think this is the best we can do. Might be something for the EJB EG to consider - Marina, happy to raise there if you want? I will create a pull req for this issue shortly with the proposed fix, please comment on the issue as ever if you do not agree with the fix, within the next two weeks. Pete

13 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (CDI-137) Changing ProcessManagedBean getBean Method Signature

by Gurkan Erdogdu (JIRA)

Changing ProcessManagedBean getBean Method Signature ---------------------------------------------------- Key: CDI-137 URL: https://issues.jboss.org/browse/CDI-137 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.0 Reporter: Gurkan Erdogdu Fix For: 1.1 (Confirmed) Currently ProcessSessionBean class signature is public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} Therefore, observers work as Example: @Stateless public class Elephant{} public void observe(ProcessBean<Elephant>) --> Not allowed public void observe(ProcessSessionBean<Elephant>) --> Allowed Pete said that main reason of using ProcessManagedBean<Object> is that "ProcessBean<X> offers a method getBean() which returns Bean<X>. Bean<X> has a method of type create() which returns an X. If we were to have ProcessSessionBean<X> extend ProcessManagedBean<X> then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is." Main reason of using the ProcessSessionBean event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. Moreover, other methods in the interface hierarchy of "ProcessSessionBean" gets <X> into the account, for example AnnotatedType<X> getAnnotatedBeanClass() Returns the AnnotatedType representing the bean class. Therefore, it is more convenient to change "ProcessManagedBean getBean" method decleration as public <T> Bean<T> getBean(); where T is the local/local view interface of the session bean. And change the ProcessSessionBean signature as public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} Also See https://issues.jboss.org/browse/CDITCK-215 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
0 / 0

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

by David Blevins (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] David Blevins commented on CDI-136: ----------------------------------- I see that these three tests are already in the excludes list due to the remove method issues. Note we'll still want to fix them so they explicitly declare @SessionScoped. org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingDecorator.EnterpriseBeanWithNonPassivatingDecoratorTest org.jboss.jsr299.tck.tests.context.passivating.broken.dependentScopedProducerMethodReturnsNonSerializableObjectForInjectionIntoStatefulSessionBean.EnterpriseBeanWithIllegalDependencyTest org.jboss.jsr299.tck.tests.context.passivating.broken.dependentScopedProducerFieldReturnsNonSerializableObjectForInjectionIntoStatefulSessionBean.EnterpriseBeanWithIllegalDependencyTest > 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 > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > > 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

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (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 edited comment on CDI-33 at 6/22/11 8:28 AM: ------------------------------------------------------- h1. Proposal Add this interface {code} interface ProcessSyntheticAnnotatedType extends ProcessAnnotatedType { Extension getSource(); } {code} A {{ProcessSyntheticAnnotatedType}} event would be fired for every {{AnnotatedType}} added via {{BeforeBeanDiscovery.addAnnotatedType()}}. This event must be fired after {{BeforeBeanDiscovery}} and before the container starts creating beans (IOW at the same time other {{ProcessAnnotatedType}} events are fired). The {{getSource}} method would return the extension instance which called {{BBD.addAnnotatedType}}. was (Author: petemuir): h1. Proposal Add this interface {code} interface ProcessSyntheticAnnotatedType extends AnnotatedType { Extension getSource(); } {code} A {{ProcessSyntheticAnnotatedType}} event would be fired for every {{AnnotatedType}} added via {{BeforeBeanDiscovery.addAnnotatedType()}}. This event must be fired after {{BeforeBeanDiscovery}} and before the container starts creating beans (IOW at the same time other {{ProcessAnnotatedType}} events are fired). The {{getSource}} method would return the extension instance which called {{BBD.addAnnotatedType}}. > 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

13 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2011