Hi Tamás!
I strongly recommend that EVERY Bean<T> should implement PassivationCapable!
The reason is the following: we need that information to serialise the proxies.
Consider you have an
@ApplicationScoped
public class MailService {....}
Of course this class doesn't need to be Serializable, because it doesn't leave
the server, right?
Now you take a
@SessionScoped
public class MailForm implements Serializable {
private @Inject MailService mailSvc;
...
}
So the MailForm instances might get serialised to another node.
With this the MailService Contextual Reference (the PROXY!) get's also
serialised along as well.
So while the MailService Contextual Instance (the actual
'application-singleton') does NOT get serialised, the Contextual Reference (the
proxy) *will*.
That means that the Bean needs to be PassivationCapable.
Ofc only the Bean<MailService>, not the Contextual Instance of the MailService!
hth.
LieGrue,
strub
> Am 06.02.2017 um 22:12 schrieb Tamás Kimmel <[email protected]>:
>
> Hi.
>
> I'm experimenting with a custom cdi context.
> I've found all Beans for non-Serializable classes are PassivationCapable (
> org.apache.webbeans.component.ManagedBean).
> getId returns an id, and beanManager.getPassivationCapableBean works on it.
> - checked Weld, and works same too -
> Are there any circumstances a Bean not instance of PassivationCapable?
>
> Is it something i can rely on?
> For example use the passivation id for key in my contextual storage even for
> beans with non-serializable beanClasses.
> I know bean classes, interceptors, and decorators have to be Serializable for
> a working passivation.
>
> Thanks in advance,
> Kimmel Tamás
>
