May 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-457) Clarify how to properly create and destroy dependent instances

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ] John Ament updated CDI-457: --------------------------- Summary: Clarify how to properly create and destroy dependent instances (was: Allow producers to provide a @TransientReference) > Clarify how to properly create and destroy dependent instances > -------------------------------------------------------------- > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

Proposal - Allow TransientReference to be used on producers.

by John D. Ament

All, I have opened a while ago - https://issues.jboss.org/browse/CDI-457 which was originally to add a disposable interface. The main driver was that if you're using an injection point like @Inject private Instance<MyDependentBean> beanInst; doing beanInst.get() can cause leaking beans since there is no creational context. Upon looking at it further, there's some effort to do this in a safer way and leverage things like TransientReference. This doesn't work for classes provided by external libraries, even the JDK itself (like String). I'd like to propose that the scope of this ticket be to allow TransientReference on producer fields/methods since right now its only allowed on types. WDYT? John

8 years, 8 months

1
1
0 / 0

Can the website auto update?

by John D. Ament

All, I was wondering, and its probably a question more for our redhat hosts, but can the website be updated automatically with spec changes? Almost like a snapshot build? John

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-457) Allow producers to provide a @TransientReference

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ] John Ament updated CDI-457: --------------------------- Description: Using @TransientReference today for class definitions allows you to mark it as dependent. We should allow arbitrary producers to include transient references. was: Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. > Allow producers to provide a @TransientReference > ------------------------------------------------ > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Using @TransientReference today for class definitions allows you to mark it as dependent. > We should allow arbitrary producers to include transient references. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-457) Allow producers to provide a @TransientReference

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ] John Ament updated CDI-457: --------------------------- Summary: Allow producers to provide a @TransientReference (was: Add a disposable interface) > Allow producers to provide a @TransientReference > ------------------------------------------------ > > Key: CDI-457 > URL: https://issues.jboss.org/browse/CDI-457 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Reporter: John Ament > Assignee: John Ament > > Currently for Dependent scoped beans, there's no way for the container to be aware when it's no longer needed. > I suggest that we somehow wrap dependent beans in a Disposable wrapper to be notified when it's not needed any longer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

Accelerate decision process and PR adoption / rejection

by Antoine Sabot-Durand

Hi guys, As you know we plan to release CDI 2.0 before the end of January. It let's us around 6 months to complete the spec. I think we really should find a way to enhance our focus on reviewing proposal and code. Adding special Hangout meetings proved itself a good solution to go that way, but I think we should also work on rules adoption for PR. So I propose that: - PR should stay open at least one week. - It could be merged (after at least a week) if 4 EG members votes for it (+1 on the PR). - As no one is error proof if someone has an objection to a PR to be merged he could raise his concern and justify his objection. - The following discussion should lead either to a revision of the PR or a +1 from the objector - If no agreement is reached, to avoid blocage a vote will be called on this ML to adopt or reject the PR. I'm not a big fan of over processed team work, but we really have to deliver. For the moment I think we can avoid having too much process on ticket choice (we don't have enough contributors to go that way) Wdyt ? Antoine

8 years, 8 months

2
2
0 / 0

[JBoss JIRA] (CDI-600) Specialization code sample is misleading

by Matej Novotny (JIRA)

Matej Novotny created CDI-600: --------------------------------- Summary: Specialization code sample is misleading Key: CDI-600 URL: https://issues.jboss.org/browse/CDI-600 Project: CDI Specification Issues Issue Type: Clarification Components: Inheritance and Specialization Affects Versions: 2.0-EDR1 Reporter: Matej Novotny In the spec, there is following code sample explaining how to achieve specialization: {code} @Alternative @Specializes public class MockAsynchronousService extends AsynchronousService { ... } {code} This is IMHO misleading as the {{@Alternative}} annotation is not needed for specialization to work and hence should be removed from this sample. In fact one user approached me recently, asking me some questions regarding CDI specialization, and this sample was a source of his confusion. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-573: ------------------------------------------ Sorry for the regression. I correct the visibility for the next beta. > Review code of CDI class to switch to ServiceLoader > --------------------------------------------------- > > Key: CDI-573 > URL: https://issues.jboss.org/browse/CDI-573 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. > In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

Meeting on?

by John D. Ament

Hey guys just wanted to check if the meeting for 5/3 is still on? John

8 years, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2016