PFD
by Pete Muir
All
Attached is the spec I intend to submit as the PFD tomorrow. You'll notice there are still a couple of issues open in the issue tracker. I don't really love the solution for https://issues.jboss.org/browse/CDI-268 that we have today, so I want to give it another nights sleep, and if I can't see any better way, I'll add what is there.
Pete
11 years, 9 months
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-228.
---------------------------
Resolution: Done
Merged
> Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-228
> URL: https://issues.jboss.org/browse/CDI-228
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> This clarification is intended for all methods which gets invoked by the CDI container and create a new @Dependent contextual instance especially for this invocation. This can happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject contructors. Basically any @Dependent method-parameter InjectionPoint.
> Despite it's atm not specified whether this @Dependent instance will get stored, most containers store it in the CreationalContext of the bean containing the invoked method. This behaviour can lead to mem leaks and non-serializibility issues.
> TASK: Define that any @Dependent contextual instance will get properly destroyed after such method invocations.
> There are 2 things we need to think about:
> 1.) any @PreDestroy method of those beans will get invoked after the method invocation, even if the @Dependent instance will stored away in a member field and still being used later. This will not make any problems in most cases. We just need to make people aware that this will happen.
> 2.) As any Decorator or Interceptor is also an @Dependent instance on our 'temporary' created @Dependent method parameter, those Interceptors and Decorators will _not_ be available after the method invocation. Storing away this bean and re-using it later will probably cause an Exception.
> I still think this is a small problem compared to creating tons of mem leaks. There are quite a few workarounds possible:
> *) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize it.
> *) We might add an additional annotation which denotes either @Transactional or au contraire: @Keep for the method-param InjectionPoint
--
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, 9 months
[JBoss JIRA] (CDI-316) Adopt usage of the @since Javadoc tag
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-316?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-316:
--------------------------
Fix Version/s: 1.1.FD
(was: 1.1.PFD)
> Adopt usage of the @since Javadoc tag
> -------------------------------------
>
> Key: CDI-316
> URL: https://issues.jboss.org/browse/CDI-316
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Javadoc and API
> Affects Versions: 1.1.PRD
> Reporter: George Gastaldi
> Fix For: 1.1.FD
>
>
> It's a good practice to use the @since javadoc tag in the methods and interfaces/classes created in this new version.
> This is necessary when one need to figure out if some feature is targeted to work in 1.1 only, for example.
> This issue was created so that all the API code can be reviewed before the next release. Some classes already have this information, other still don't (@Vetoed is one that is missing, afaik)
--
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, 9 months