[cdi-dev] Proxy implementation leaks

[Arne Limburg]

Hi Christian,

The first call to your constructor is used to create the "contextual reference" and the second is used to create your actual "contextual instance".
As long as your scope is active you will not get a third call to your constructor since you always get the same "contextual instance".
When you make a new lookup you 'may' get a new "contextual reference". If weld is smart enough you will get the same contextual reference (and hence your constructor is not called again), but this is explicitly not required by the spec.

Regards,
Arne

-----Ursprüngliche Nachricht-----
Von: cdi-dev-bounces at lists.jboss.org [mailto:cdi-dev-bounces at lists.jboss.org] Im Auftrag von Pete Muir
Gesendet: Montag, 9. Mai 2011 16:50
An: Christian Bauer
Cc: cdi-dev at lists.jboss.org
Betreff: Re: [cdi-dev] Proxy implementation leaks


On 9 May 2011, at 15:46, Christian Bauer wrote:

> Started working with Weld 1.1.1 and found two issues that probably should be addressed (maybe just documented). They both look to me like leaking implementation details because proxies are used for components which are not @Singleton or @Dependent.
> 
> @ApplicationScoped
> public class Bug {
> 
>   public Bug() {
>       System.out.println("########## CONSTRUCT");
>   }
> 
>   public void foo() {
>       System.out.println("##### FOO");
>   }
> 
>   public static void main(String[] args) {
>       Weld weld = new Weld();
>       WeldContainer weldContainer = weld.initialize();
> 
>       Bug bug = weldContainer.instance().select(Bug.class).get(); // Creates new instance of Bug
>       bug.foo(); // Creates new instance of Bug!!!
>       bug.foo(); // Uses existing instance
> 
>       weld.shutdown();
>   }
> }
> 
> The proxy of Bug will call its superclass constructor several times during the lifecycle of the Bug component. I don't know if that is really necessary, but if it is, you can now no longer use constructors to initialize your component. This is an issue because
> 
> - it's not documented that constructors of @ApplciationScoped (etc., proxied) components behave differently than @Singleton/@Dependent constructors
> 
> - even if it's documented, it's questionable if that really should be the case.
> 
> Taking away constructors as the primary means of initializing a component - e.g. obtaining resources such as database connections, reading config files, etc. - is a major change in the Java programming model. Users have to be strongly advised to use @PostConstruct then.

Stuart, I though subclassing proxies should resolve this?
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev