[JBoss JIRA] (CDI-239) Define Extension notification rules for shared libraries
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-239?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-239:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Define Extension notification rules for shared libraries
> --------------------------------------------------------
>
> Key: CDI-239
> URL: https://issues.jboss.org/browse/CDI-239
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Fix For: 1.1.PFD
>
>
> Consider an EAR file with a shared xy.JAR file in the EARs ./lib folder with an
> @EnterpriseApplicationScoped class X
> and a
> @RequestScoped class Y
> The EAR also contains 2 web applications WebAppA and WebAppB.
> WebAppA has ExtensionA in it's WEB-INF/classes and WebAppB has ExtensionB in it's classes both with a public void met(@Observes ProcessAnnotatedType pat) and each modifying the AnnotatedType.
> What should happen here? Will there be 2 Bean<T> for X and 2 for Y? (one Bean for each WebApp)? or will X and Y not trigger a ProcessAnnotatedType for the extensions defined in the webapps (but only for Extensions defined in the shared ear lib)?
--
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
11 years, 10 months
[JBoss JIRA] (CDI-139) Support for unmanaged instances
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-139:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Support for unmanaged instances
> -------------------------------
>
> Key: CDI-139
> URL: https://issues.jboss.org/browse/CDI-139
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Joshua Davis
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> Allow the creation of unmanaged instances. The CDI context will not keep track of these instances and the application will be responsible for cleaning them up. This is a fairly typical usage of other DI frameworks such as Guice and PicoContainer.
> Currently, if an ApplicationScoped object injects an {{Instance<T>}} interface, CDI will manage all instances returned by the {{get()}} method as dependents of the application scoped object. Those instances will be kept in memory by the CDI implementation and will only be GC'd when the application scoped object is destroyed (at the end of the application). This may look like a memory leak to the user (see WELD-920).
> From P. Muir on WELD-920
> {quote}
> We can describe instances which are attached (as the CDI 1.0 spec requires) as "managed" instances, and those which the user takes responsibility for cleaning up themselves as "unmanaged" instances. In CDI 1.1 I would like to add support for unmanaged instances (the impl will just hand these over and forget about them) and also to allow the app to request an unmanaged instance is cleaned up. Please can someone file a CDI issue for this?
> Weld could certainly be more friendly and more proactively discard instances. Ideas:
> 1) Analyse the dependent instance graph, and if there are no @PreDestroy/@Disposer callbacks on in the graph, do not store the dependent instance for cleanup (this would be a good general optimization
> (2) Add a config option to allow instances created from Instance to be held only as long as the app holds a reference, and if the app doesn't hold a reference for it's lifetime, then Weld would not do any cleanup (Weld would hold a weak ref).
> {quote}
--
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
11 years, 10 months
[JBoss JIRA] (CDI-278) Clarify scope of Stateless and Singleton EJB's
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-278?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-278:
-------------------------------
[~struberg] what was the conclusion here?
> Clarify scope of Stateless and Singleton EJB's
> ----------------------------------------------
>
> Key: CDI-278
> URL: https://issues.jboss.org/browse/CDI-278
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Stuart Douglas
> Fix For: 1.1 (Proposed)
>
>
> At the moment Stateless and Singleton beans are classified as @Dependent scope by default, which is not really very useful, as a lot of the rules for dependent scoped beans simple do not apply to them (they violate pretty much every rule for dependent scoped beans in 6.4).
> I think we need to define a new scope for these beans, or at least clarify their behaviour when they are @Dependent scoped.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ]
Pete Muir updated CDI-3:
------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
> ------------------------------------------------------------------------------------------------------------
>
> Key: CDI-3
> URL: https://issues.jboss.org/browse/CDI-3
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes.
> Some of the things that the bean interface will not let you mimic are:
> - Interceptors
> - Disposal methods
> - Producer fields for normal scoped beans
--
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
11 years, 10 months
[JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-200?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-200:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> ProcessBeanAttributes needs clarification
> -----------------------------------------
>
> Key: CDI-200
> URL: https://issues.jboss.org/browse/CDI-200
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Labels: visibility
> Fix For: 1.1.PFD
>
>
> The specification should clarify the following cases:
> (1) whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be.
> (2) whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required)
> (3) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options:
> (a) the container takes the final values of a BeanAttributes object and uses them
> (b) the container itself updates certain attributes to match CDI rules for example
> ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute
> In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient.
> Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are:
> (4) In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name.
> (5) Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-84) Non EE modules should be able to inject/lookup in JNDI a BeanManager
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-84:
-------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Non EE modules should be able to inject/lookup in JNDI a BeanManager
> --------------------------------------------------------------------
>
> Key: CDI-84
> URL: https://issues.jboss.org/browse/CDI-84
> Project: CDI Specification Issues
> Issue Type: Tracker
> Components: Java EE integration, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Labels: visibility
> Fix For: 1.1.PFD
>
>
> EE.5.19
> A bean manager is only available in modules in which CDI has been enabled.
> Where EE modules are defined to be; ejb-jar, rar, client jar and war.
> This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation.
> Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop.
--
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
11 years, 10 months