[JBoss JIRA] (CDI-209) BeanManager.createProducer missing in the API
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-209:
-----------------------------------
Summary: BeanManager.createProducer missing in the API
Key: CDI-209
URL: https://issues.jboss.org/browse/CDI-209
Project: CDI Specification Issues
Issue Type: Bug
Components: Portable Extensions
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
The spec says:
{quote}
The method BeanManager.createProducer() returns a container provided implementation of Producer for a given AnnotatedMethod or AnnotatedField or throws an IllegalArgumentException if there is a definition error associated with the producer method or field.
{quote}
However, the createProducer() method is not defined in the API.
--
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, 8 months
[JBoss JIRA] (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 reassigned CDI-136:
-----------------------------
Assignee: Jozef Hartinger (was: Pete Muir)
> 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: Jozef Hartinger
> 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, 8 months
[JBoss JIRA] (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 commented on CDI-136:
-------------------------------
https://github.com/jboss/cdi/pull/63
Jozef, could you review?
> 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, 8 months
Re: [cdi-dev] CDI EG requires feedback
by Pete Muir
On 15 Aug 2012, at 15:30, Stuart Douglas wrote:
>
> On 15/08/2012, at 11:20 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>> All, the CDI EG requires feedback on an item in the spec which is not clear, and has been implemented differently between implementations, and is not TCK tested. As Deltaspike contains lots of extensions authors, requesting feedback. Please either send direct to me, or post to cdi-dev(a)lists.jboss.org :-)
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Multiple Annotated Types
>> ====================
>>
>> https://issues.jboss.org/browse/CDI-58
>>
>> This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this.
>>
>> We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change).
>>
>> We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route.
>>
>
>
> I think there are some issues here. In order to get consistent behaviour the XML extension relied upon PAT being fired for every class it defined, so other extension could then modify the annotated type in a consistent manner.
IOW this would prevent XML defined class from then being modified by another extension.
>
> Later on Weld changed its behaviour so that PAT was not fired when annotated types were added through the SPI, in order to work around this I made the XML extension fire PAT for these type itself in order to provide backwards compatibility, which is a horrible hack that is now causing problems for Delta Spike.
>
> If we make this change to the specification I don't think that it will be possible to implement a viable XML extension.
The XML would work but couldn't have it's behaviour changed by other extensions.
>
> I am aware that this present challenges for serialisation and clustering, however I worked around this in Weld when I was writing the XML extension by creating a class that creates a deterministic bean id based on the annotations on the class (https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...), I wrote this code before I was working for Red Hat an I am quite happy to license it under Apache or any other license.
Weld is Apache licensed anyway. I think it's fair to define this approach of creating a type id as "not easy".
>
> Stuart
>
>
>> ------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Does anyone create multiple AnnotatedTypes per class instance? If so, can you please describe:
>>
>> a) why you need to do this
>> b) whether you could reimplement by directly creating beans (given that CDI 1.1 allows you to [1])
>> c) how much effort it would be to reimplement/how much of your codebase this would affect
>>
>> Thanks!
>>
>> Pete
>>
>> [1]
>>
>> BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
>> InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
>> Bean b = beanManager.createBean(ba, clazz, it);
>>
>> or
>>
>> BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
>> Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
>> Bean b = beanManager.createBean(ba, clazz, p);
>>
>> The Bean can then be registered using
>>
>> afterBeanDiscovery.addBean(b);
>>
>>
>
11 years, 8 months
Minutes/Notes from CDI EG meeting (hangout) on 13th August
by Pete Muir
Present
======
Pete Muir
Mark Struberg
Jozef Hartinger
Martin Kouba
Jason Porter
Joe Bergmark
Fabien Marsuad
Minor items
=========
Mark ran us through https://github.com/jboss/cdi/pull/58 and we agreed with his approaches. These are principally clarifiactions.
Mark ran us through https://issues.jboss.org/browse/CDI-247 and we agreed that Martin's proposal of using the default value, as defined by the JLS, could be injected if a a producer returned null for a primitive type wrapper. This is a backwards compatible change, as previously attempting to return null on such a producer resulted in a runtime exception.
Action: Pete to review and apply pull requests
Multiple Annotated Types
====================
We then moved on to discuss https://issues.jboss.org/browse/CDI-58. This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this.
We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change).
We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route.
Action: Pete to contact extension authoring groups, and verify that this approach will work and have minimum impact on existing extensions
Visibility of container invoked methods
==============================
Currently the CDI specification does not limit the visibility of container invoked methods (observers, producers, initializers). We propose that this should be limited to non-private methods, as otherwise we run into extensive incompatibles with other specs such as EJB, and VMs (such as IBM JDK). Furthermore, having the container invoke private methods deliberately breaks the intended purpose of visibility in Java.
Action: Pete to propose change to spec
Lack of symmetry between AnnotatedType hierarchy and class hierarchy
========================================================
CDI exposes a flat (merged) annotated type hierarchy whilst Java specifies a hierarchical model. We concluded this doesn't matter, as the identity of all elements on an AnnotatedType is it's signature, which includes the declaring class. In most cases the declaring class is not relevant, the only case in which it is, is injected private fields. We believe the clearly specifying what makes up an AnnotatedType (public methods with overrides resolved, public constructors, all fields) in addition to the addressing the visibility issue will resolve this issue. We need to do this analysis taking into account the inheritance rules specified in CDI and @Inject specs.
Action: Pete to draft up proposal
11 years, 8 months
inject into bean produced by portable extension
by JJ Snyder
Is it possible for a bean produced by a portable extension to have
injection? For example, I have
public class BeanA() {
@Inject
private BeanB beanB
...
}
public class BeanB() {}
Both beans are created by the portable extension and added (via addBean)
in the afterBeanDiscovery method. When I deploy a war I get
"WELD-001408 Unsatisfied dependencies" for the private field beanB. The
portable extension is on the system classpath and not part of the war.
I'm using Weld 1.1.8.Final
thanks,
JJ
11 years, 8 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-18:
----------------------------------
The whole BDA discussion is also important for Beans added via Extensions. Such Beans do not have any BDA. Same question applies if AnnotatedType gets modified or added freshly via Extensions. What BDA are they assigned to?
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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, 8 months
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers, interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-4:
-----------------------------
If we allow a reordering in a portable extension, Linda suggested that the order from XML should be used as a default.
> Need a way to provide ordering for Event observers, interceptors, decorators and alternatives
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
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, 8 months
AnnotatedType discussion
by Mark Struberg
Hi Pete, others!
I found the issue I was searching for:
https://issues.jboss.org/browse/CDI-58
One of the discussions in the EG meeting was about whether we like to have 1 AnnotatedType per physical class or if we allow for multiple of them.
Both ways have pros and cons.
If we just have one AT per Class, I think we don't need the freshly introduced ProcessSyntheticAnnotatedType neither. Especially the trick with the getSource() sounds pretty error prone to me.
LieGrue,
strub
11 years, 8 months
