7:17 a.m.
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
7:34 a.m.
New subject: [JBoss JIRA] Updated: (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Joshua Davis updated CDI-139:
-----------------------------
Forum Reference: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
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
8:16 a.m.
New subject: [JBoss JIRA] Updated: (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-139:
--------------------------
Fix Version/s: 1.1 (Proposed)
Forum Reference: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
(was: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark)
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
Fix For: 1.1 (Proposed)
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
8:07 a.m.
New subject: [JBoss JIRA] Commented: (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
Proposal for method names is {{dispose()}} or {{destroy()}}. You would need to use the
same Instance to destroy a dependent instance as you used to create it (error otherwise).
To try to destroy a non dependent scoped bean would be an error.
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
Fix For: 1.1 (Proposed)
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
1:07 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-139:
-----------------------------------
I think we don't need anything like that. It happens that all (non EG) people I talked
about this very problem (using Instance<T> for creating @Dependent beans) did not
even understand that they created a memory leak!
What can we do against it? We could of course add a destroy(Object) instance, but this
might be hard to use. Of course, users would really need to use it and old code would
still be broken.
My solution: the injected Instance<T> itself is a managed contextual instance as
well, and it has Scope @Dependent. Thus it is possible to add a @PreDestroy to it which
will automatically get called by the container whenever the containing contextual instance
will get destroyed.
If we now in Instance#get() check if the created contextual instance is @Dependent and
then store it in a List inside the respective Instance<T> instance, then we can also
easily cleanup them in the @PreDestroy of Instance<T> which got used to create all
the Dependent contextual instances.
Thus we would not create any mem leaks anymore.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:04 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-139:
-----------------------------------
Of course that would mean that @Dependent contextual instances which get destroyed when
the bean which contains the Instance<T> will get destroyed. That's almost ever
the case, but we should make it clear.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:50 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Arne Limburg commented on CDI-139:
----------------------------------
Additionally we need to specify, when @Dependent instances that are obtained via
CDI.current() or BeanManager.getReference(...) are destroyed. At least this should be
happen on container-shutdown.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:58 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-139:
-----------------------------------
At least this should be happen on container-shutdown.
definitely true for CDI.current().
For BeanManager#getReference() I just would clarify that users of this method (most
probably only CDI Extensions) must take care of cleaning up @Dependent beans via
Bean#destroy theirselfs.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:22 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
I think we don't need anything like that. It happens that all
(non EG)
people I talked about this very problem (using Instance<T> for creating
@Dependent beans) did not even understand that they created a memory leak!
What can we do against it? We could of course add a destroy(Object) instance,
but this might be hard to use. Of course, users would really need to use it
and old code would still be broken.
My solution: the injected Instance<T> itself is a managed
contextual instance
as well, and it has Scope @Dependent. Thus it is possible to add a @PreDestroy
to it which will automatically get called by the container whenever the containing
contextual instance will get destroyed.
If we now in Instance#get() check if the created contextual instance is @Dependent
and then store it in a List inside the respective Instance<T> instance, then we
can also easily cleanup them in the @PreDestroy of Instance<T> which got used to
create all the Dependent contextual instances.
Yes, we should certainly clarify that this is the behavior required, and this is actually
what creates the "memory leak" in the first place. The issue is most apparent
you associate the Instance with an application scoped bean, it means the memory won't
be released until the application is undeployed. This is correct, but has unfortunate side
effects.
Weld implements this today, not via the impl you propose, but it has the same effect.
There are a few optimisations we can do - if there is no @PreDestroy callback on the
dependent bean, there is no need to hold a reference to it at all. We could also offer a
mode where only a weak reference is held by Weld, so that when the app drops a reference,
it can be gc'd.
We could of course suggest people don't use Instance with application scoped beans,
but this seems a bad restriction.
I think offering a mode where people can manually clean up their Instances is useful. It
won't affect the functionality of an app if you don't use it, but it can offer an
optimisation people can use.
Additionally we need to specify, when @Dependent instances that are
obtained via CDI.current() or
BeanManager.getReference(...) are destroyed. At least this should be happen on
container-shutdown.
Beans obtained via BeanManager must be manually cleaned up using Contextual.destroy().
We should add that instances obtained via CDI.current() will be treated as belonging to
the lifecycle of the application, and so automatically cleaned up when the application is
stopped. Can you file an issue for that?
IMO this latter point also emphasises the need for a Instance.destroy() method, most of
the time people will want their beans cleaned before the application is stopped.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:13 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-139:
-----------------------------------
Just a short notice:
I think this should get added to the spec that way we discussed: automatically destroying
all @Dependent contextual instances created via the Instance<T>.get() method when
the containing bean will be destroyes.
This will of course have a few side effects where this might be too aggressive:
Consider the following code:
@RequestScoped
public class X {
private @Inject Instance<Y> yProvider;
private static Y y;
@PostConstruct
void doInit() {
if (y == null) y = yProvider.select().get();
}
}
In this case we would 'destroy' y (calling @PreDestroy) at the end of the Request,
even if the static y member is still valid.
The same might happen if you store y somewhere else via classic java setters...
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:29 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
Haha, yes. However I hope that people don't actually write code like that with CDI
:-)
But generally, yes, let's do this.
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
Fix For: 1.1 (Proposed)
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:27 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
Here is a proposal, to add a release() method:
https://github.com/jboss/cdi/pull/100
This is useful for both the mem leak issue, as it allows a bean to declare it no longer
needs a reference, and also for unmanaged instances.
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
Fix For: 1.1.PRD
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
1:27 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-139:
--------------------------
Assignee: Pete Muir
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
Forum Reference: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
(was: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark)
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.PRD
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
6:48 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
The proposal has been updated to account for CDI-89. Open issue is
OPEN ISSUE: What name should the AlterableContext interface be given?
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.PRD
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:31 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir resolved CDI-139.
---------------------------
Resolution: Done
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.PRD
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
1:03 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir reopened CDI-139:
---------------------------
This wasn't as fixed as I thought :-(
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.PRD
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
1:05 p.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
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.PRD)
Forum Reference: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
(was: http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark)
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
4:14 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-139:
--------------------------
Fix Version/s: 1.1 (Proposed)
(was: 1.1.PFD)
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 (Proposed)
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:38 a.m.
New subject: [JBoss JIRA] (CDI-139) Support for unmanaged instances
[
https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-139:
-------------------------------
Our best idea here is to standardize an abstract helper class that users can extend to
make this easier, as passing around the CreationalContext really is necessary.
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 (Proposed)
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
4176
days inactive
4683
days old
18 comments
6 participants
participants (6)
-
Arne Limburg (Commented) (JIRA) -
Joshua Davis (JIRA)
-
Mark Struberg (Commented) (JIRA)
-
Mark Struberg (JIRA)
-
Pete Muir (Commented) (JIRA)
-
Pete Muir (JIRA)