March 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined

by Mark Struberg (JIRA)

Mark Struberg created CDI-220: --------------------------------- Summary: behaviour of CDI bean @Specializes session bean is undefined Key: CDI-220 URL: https://issues.jboss.org/browse/CDI-220 Project: CDI Specification Issues Issue Type: Clarification Components: Java EE integration Affects Versions: 1.1.EDR1, 1.0 Reporter: Mark Struberg Fix For: TBD The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. @Stateless public class Horse {..} @ApplicationScoped @Specializes public class Drakener extends Horse {..} Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- 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

12 years, 9 months

2
4
0 / 0

Support Request (and Conversation?) Scope in @Singleton @Startup @PostConstruct methods

by Guido Bonazza

Hello everyone! Checking out the CDI 1.0 spec and actually trying it on JBoss AS 7.1.0.Final it seems to me that the Request Scope is not active in @Singleton @Startup @PostConstruct method, so I'd like to propose this use case to be supported in the next version of CDI. Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is no reason why the ConversationScope should be any less available than the RequestScope"), I think that conversation scope should be available too in this context. It would be very useful, for example, when you have an EntityManager produced in conversation scope (mostly used in JSF contexts), to be allowed to use it @Singleton @Startup @PostConstruct methods. Of course there should be some limitations in this case (long running conversation promotion shouldn't be allowed for example), but the basic case should be supported in my opinion. Thanks for the attention, Guido

12 years, 9 months

5
9
0 / 0

Are we always able to invoke @PreDestroy for @Dependent beans?

by Mark Struberg

My answer sadly is no. Dependent objects are stored in the CreationalContext which is held in the context which holds the outer NormalScoped contextual instance. If the outer NormalScoped contextual instance gets desroyed, we also properly destroy all @Dependent beans in the CreationalContext. So far so good, but now let's consider hte following scenario: @ApplicationScoped public class MyService { void doStats(@Observes RequestStatistics, UserHelper uh) { UserHelper is @Dependent and a new instance will get created each time doStats() gets called. What happens is that we don't know whether the UserHelper internally gets stored or just thrown away. In our sample most probably the later. Each UserHelper will get stored in the CreationalContext of our single MyService instance. After 500.000 requests, our CreationalContext would contain 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... What we can do is to store only WeakReferences. E.g. via a WeakHashmap. This will automatically drop the entries if the instances in it get garbage collected. But in this case are not able to invoke @PreDestroy anymore I fear, because gone is gone ... LieGrue, strub

12 years, 9 months

7
16
0 / 0

Dealing with non-passivation-capable dependencies of a normal-scoped bean

by Jozef Hartinger

Hello, with https://github.com/jboss/cdi/pull/47 in place the validation rules for dependencies of normal-scoped components have been weakened. The idea is that CDI should not enforce dependencies to be passivation capable if these dependencies are only used temporarily in the initialization of a normal-scoped bean. Consider the following example: @SessionScoped public class Foo implements Serializable { @Inject public Foo(Bar bar) { } } public class Bar { } CDI now considers this scenario to be valid. However, the Bar instance is still technically a dependent instance of Foo and the container still needs to retain a reference to it in order to destroy it properly. The problem arises when the session is serialized. Although the Foo instance does not reference the Bar instance and can therefore be serialized, the CreationalContext of Foo still holds the dependent instance and is therefore not serializable. I came up with an idea of how to implement it in Weld at https://issues.jboss.org/browse/WELD-1076 . However, I do not consider this approach to be very clean and intuitive for specification implementors. Therefore, I want to make sure that the specification is really intended to be implemented this way and that this is not an oversight in the specification. JH

12 years, 10 months

3
2
0 / 0

Fwd: [jsr345-experts] [Fwd: [javaee-spec users] [jsr342-experts] Re: Due date for Java EE 7]

by Pete Muir

FYI, CDI also uses the same schedule. We need to ramp up activity again (mainly my fault we've slowed), I hope to spend some time in April on CDI. Begin forwarded message: > From: Marina Vatkina <marina.vatkina(a)oracle.com> > Subject: [jsr345-experts] [Fwd: [javaee-spec users] [jsr342-experts] Re: Due date for Java EE 7] > Date: 6 March 2012 00:26:13 GMT > To: jsr345-experts(a)ejb-spec.java.net > > An update on the Java EE 7 dates. EJB 3.2 uses the same schedule as the Platform. > > -marina > > -------- Original Message -------- > Subject: [javaee-spec users] [jsr342-experts] Re: Due date for Java EE 7 > Date: Mon, 05 Mar 2012 16:20:55 -0800 > From: Bill Shannon <bill.shannon(a)oracle.com> > Reply-To: jsr342-experts(a)javaee-spec.java.net > To: jsr342-experts(a)javaee-spec.java.net > References: <CA+ZZq98dS7eJ6tpefFhfD4OKLAwRN_-i7E3Q3ZT9CLN-RGLh_Q(a)mail.gmail.com> > > > > Antonio, your question is very timely. We've recently completed > a planning exercise for all of our upcoming work on GlassFish, > including the Java EE 7 RI and TCK work. Based on the resources > we have available, our prioritization of the work to be done, > and the current state of the various Java EE specifications, it's > clear that the original dates are no longer achievable. > > We believe that an end date of late Q1 or early Q2, 2013, is more > realistic. We plan to have a mostly complete preview release of the > implementation available in time for JavaOne. We'd like to see all > Java EE 7 specifications at the Public Review stage by this time, > and the implementations in sync with those specifications. This should > give us time to get some real developer feedback and react to it before > the final release. > > We'll provide a more detailed schedule with milestones for the > GlassFish 4.0 reference implementation release soon at this URL: > https://wikis.oracle.com/display/GlassFish/PlanForGlassFish4.0 > > > Antonio Goncalves wrote on 03/02/12 00:17: >> Hi all, >> >> I've been asked several times when will Java EE 7 officially be out. Are we >> still targeting Q4 2012 ? Begenning or end ? Or will we speed up things because >> of JavaOne (end of Sep) which will be end of Q3 / beginning of Q4. >> >> Just wondering >> >> -- >> Antonio Goncalves >> Software architect and Java Champion >> >> Web site <http://www.antoniogoncalves.org> | Twitter >> <http://twitter.com/agoncal> | Blog >> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn >> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org> >

12 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2012