[JBoss JIRA] Created: (CDI-129) introduce @EnterpriseScoped (or similar)
by Mark Struberg (JIRA)
introduce @EnterpriseScoped (or similar)
----------------------------------------
Key: CDI-129
URL: https://issues.jboss.org/browse/CDI-129
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts
Affects Versions: 1.0
Reporter: Mark Struberg
Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
We could (ab-)use @Singleton for that, but this is currently not well defined at all.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (CDI-164) Decorating built in beans
by Jozef Hartinger (JIRA)
Decorating built in beans
-------------------------
Key: CDI-164
URL: https://issues.jboss.org/browse/CDI-164
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Decorators
Affects Versions: 1.0
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
In CDI 1.0, decorators may only be applied to managed and session beans. Decorating built-in beans would make CDI extensions more powerful.
One of the possible usecases is represented by decorating the Event bean https://gist.github.com/1223042
This would allow extensions to implement for example:
* event queuing (Forge)
* bidirectional mapping to another event technology without introducing infinite loops (Seam JMS)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (CDI-139) Support for unmanaged instances
by Joshua Davis (JIRA)
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (CDI-132) Clarify which initial info AnnotatedType should contain
by Mark Struberg (JIRA)
Clarify which initial info AnnotatedType should contain
-------------------------------------------------------
Key: CDI-132
URL: https://issues.jboss.org/browse/CDI-132
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Mark Struberg
The spec is not exactly clear about the initial content of AnnotatedType.
When initially building the AnnotatedType (e.g. before handing it over to the Extensions) we need to pre-fill them with the info from the annotations from the classes.
Should this AnnotatedType:
1.) contain no annotations from superclasses?
2.) contain all annotations from superclasses?
3.) contain @Inherited annotations from superclasses?
I think the other questions already got cleared up in CDI-70:
Should AnnotatedType contain derived public? protected? private? methods/fields from a superclass?
Imo it should contain all information which would be available by manually parsing any annotations. In other words: it should be possible to completely modify or emulate annotations of a parsed type.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (CDI-123) Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification
by Richard Hightower (JIRA)
Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification
-----------------------------------------------------------------------------------------------------------------------------
Key: CDI-123
URL: https://issues.jboss.org/browse/CDI-123
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Concepts
Affects Versions: 1.1 (Proposed)
Reporter: Richard Hightower
Fix For: 1.1 (Proposed)
Using Seam's CDI XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification.
Annotations and Alternatives should always be the first line of offense for doing injection, decoration and interception. However, there are times when you want to configure things that don't fit well into this model. This is also useful for testing.
This is not to give up type safeness via annotations, but to have some additional flexibility.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (CDI-120) Add an optional Portlet specification support
by Mark Struberg (JIRA)
Add an optional Portlet specification support
---------------------------------------------
Key: CDI-120
URL: https://issues.jboss.org/browse/CDI-120
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts
Reporter: Mark Struberg
We should mention the portlet specification and how CDI-1.1 should be utilised/supported in a portlet environment.
This is an important prerequisite for the JSR-344 EG to deprecate the JSF @javax.faces.bean.ManagedBean capabilities.
Imo there is currently no argument which prevents to run a CDI container from running in a portlet environment anyway. No CDI interface imports any javax.servlet.* class.
It could affect the wording in 6.5.2. which defines the built in scopes as being 'as defined in the Servlet specification'. We could easily extend this to also cover the portlet definition.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month