Hi! I'm just curious how Weld manages to inject a Logger into a @SessionScoped (passivating!) bean. In your example in 1.3.5 you wrote: > class Loggers { > @Produces Logger getLogger(InjectionPoint injectionPoint) { > return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getSimpleName() ); > } > } and > @SessionScoped > public class Permissions implements Serializable { > @Inject Logger log; > ... but the Logger I know are actually not Serializable themselfs and since it is @Dependent scoped, we also don't use a proxy for it.

I'd expected a DeploymentException thrown at startup in this case, but Weld actually seems to only checks passivation stuff for NormalBeans. Anyway, once the session get's passivated, you'll see a fine NotSerializableException.

> I think you must use a proxy. But 'you' means the programmer of the application has to do this manually and not the container, isn't? Supporting static injection would really be cool in this case! Or supporting re-injection after re-activation (would be more difficult I guess). LieGrue, strub --- Pete Muir <pmuir(a)redhat.com&gt; schrieb am Di, 16.2.2010: > Von: Pete Muir <pmuir(a)redhat.com&gt; > Betreff: Re: [weld-dev] Passivating Capabilities check. > An: "Mark Struberg" <struberg(a)yahoo.de&gt; > CC: weld-dev(a)lists.jboss.org > Datum: Dienstag, 16. Februar, 2010 12:40 Uhr > > On 16 Feb 2010, at 10:11, Mark Struberg wrote: > >> Hi! >> >> I'm just curious how Weld manages to inject a Logger > into a @SessionScoped (passivating!) bean. >> >> In your example in 1.3.5 you wrote: >> >>> class Loggers { >>> @Produces Logger > getLogger(InjectionPoint injectionPoint) { >>> return > Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getSimpleName() > ); >>> } >>> } >> >> and >>> @SessionScoped >>> public class Permissions implements Serializable > { >>> @Inject Logger log; >>> ... >> >> but the Logger I know are actually not Serializable > themselfs and since it is @Dependent scoped, we also don't > use a proxy for it. > > I think you must use a proxy. > >> >> I'd expected a DeploymentException thrown at startup > in this case, but Weld actually seems to only checks > passivation stuff for NormalBeans. Anyway, once the session > get's passivated, you'll see a fine > NotSerializableException. > > Well, the passivation capability is checked (of > Permissions), which includes checking whether the producer > method is passivation capable (it is, even though Logger > isn't serializable, it also isn't final, so you might return > a serializable subclass). > > I would however expect Weld to throw an > IllegalProductException - I wrote this test which shows it > does :-) > > http://fisheye.jboss.org/browse/weld/core/trunk/tests/src/test/java/org/j... __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com

Von: Sven Linstaedt <sven.linstaedt(a)googlemail.com&gt; Betreff: Re: [weld-dev] Passivating Capabilities check. An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: "Pete Muir" <pmuir(a)redhat.com&gt;, weld-dev(a)lists.jboss.org Datum: Mittwoch, 17. Februar, 2010 01:13 Uhr Hi Mark, so if the Logger is not serializable, but insteads gets reinjected (and therefore recreated?) after deserialization of the owning bean, what lifecycle has the Logger bean? IMHO it would only make sense to destroy the logger, if it is not serialized with the owning bean. Currently the @Dependent scoped bean inherits the lifespan of the owning bean. In addition... do you have any clue if there is a CDI counterpart for EJB's @PrePassivate and @PostActivate handles? br, Sven 2010/2/16 Mark Struberg <struberg(a)yahoo.de&gt; > I think you must use a proxy. But 'you' means the programmer of the application has to do this manually and not the container, isn't? Supporting static injection would really be cool in this case! Or supporting re-injection after re-activation (would be more difficult I guess). LieGrue, strub --- Pete Muir <pmuir(a)redhat.com&gt; schrieb am Di, 16.2.2010: > Von: Pete Muir <pmuir(a)redhat.com&gt; > Betreff: Re: [weld-dev] Passivating Capabilities check. > An: "Mark Struberg" <struberg(a)yahoo.de&gt; > CC: weld-dev(a)lists.jboss.org > Datum: Dienstag, 16. Februar, 2010 12:40 Uhr > > On 16 Feb 2010, at 10:11, Mark Struberg wrote: > > > Hi! > > > > I'm just curious how Weld manages to inject a Logger > into a @SessionScoped (passivating!) bean. > > > > In your example in 1.3.5 you wrote: > > > >> class Loggers { > >>   @Produces Logger > getLogger(InjectionPoint injectionPoint) { > >>       return > Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getSimpleName() > ); > >>   } > >> } > > > > and > >> @SessionScoped > >> public class Permissions implements Serializable > { > >>   @Inject Logger log; > >> ... > > > > but the Logger I know are actually not Serializable > themselfs and since it is @Dependent scoped, we also don't > use a proxy for it. > > I think you must use a proxy. > > > > > I'd expected a DeploymentException thrown at startup > in this case, but Weld actually seems to only checks > passivation stuff for NormalBeans. Anyway, once the session > get's passivated, you'll see a fine > NotSerializableException. > > Well, the passivation capability is checked (of > Permissions), which includes checking whether the producer > method is passivation capable (it is, even though Logger > isn't serializable, it also isn't final, so you might return > a serializable subclass). > > I would however expect Weld to throw an > IllegalProductException - I wrote this test which shows it > does :-) > > http://fisheye.jboss.org/browse/weld/core/trunk/tests/src/test/java/org/j... __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev