[cdi-dev] Question for clarification and my understanding

Thu Oct 20 03:08:03 EDT 2011

Actually the trick with the byte-code engineered default ct is exactly as JVM dependent as Serialization in certain VMs and constellations don't need a default ct.
We should not require both of them imo.

As for the non-private default ct: are we d'accord that proxying won't work without a non-private ct? Thus a @NormalScoped bean must have a non-private ct?

Thus the question that remains is only whether interception of @Dependent beans with a non-private ct must work or not?

LieGrue,
strub

>________________________________
>From: Stuart Douglas <stuart.w.douglas at gmail.com>
>To: Mark Struberg <struberg at yahoo.de>
>Cc: Jozef Hartinger <jharting at redhat.com>; cdi-dev <cdi-dev at lists.jboss.org>
>Sent: Thursday, October 20, 2011 8:33 AM
>Subject: Re: [cdi-dev] Question for clarification and my understanding
>
>
>
>
>On 20/10/2011, at 5:19 PM, Mark Struberg wrote:
>
>They must have at least 1 non-private ct (this includes the default ct). And if it does have a parameter, then it must be annotated with @Inject.
>>This is perfectly enough to create a proxy. Of course this @Inject constructor must not get called while creating the proxy itself (because this might contain certain checks and logic). In this very case a default-ct must get added to the proxy-subclass via byte code enhancement techniques.
>>
>
>
>That does not really work, according to the JVM spec: 
>
>
>http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html
>
>
>4.8.2 Structural Constraints - "Each instance initialization method (§3.9), except for the instance initialization method derived from the constructor of class Object, must call either another instance initialization method of this or an instance initialization method of its direct superclass super before its instance members are accessed. However, instance fields of this that are declared in the current class may be assigned before calling any instance initialization method."
>
>
>So even if you add a default constructor to the sub class, this default constructor still has to call the non default constructor of the superclass. It is possible to pass 'default' arguments (i.e. null for objects and 0 for primitives), but this is kinda dodgy, and can result in NPE's if the constructor is expecting a non-null value. All JVM's also provide a non-portable way to instantiate a class without calling the constructor (such as com.sun.misc.Unsafe), however as this is not really an official part of java platform it is not really something a spec should rely on. 
>
>
>So even though it is not impossible to do, it is not very well specified and kinda fragile, or just plain non-portable. 
>
>
>
>
>>
>>Also please note that not the CDI specification defines any interceptor behaviour but the Interceptors-1.1 specification (or any update which gets defined by the EJB-3.2 Expert Group). So any assumption we made in CDI must be synced with their work.
>>
>>
>
>
>The interceptors specification does not really have much to say on this. It seems to assume that the proxiability requirements will be taken care of by the specification that defines the component type that is being intercepted. 
>
>
>>And actually, all beans of passivating scopes must provide a default-ct because of Serialization reasons anyway, isn't?
>>
>>
>
>
>A default constructor is not a requirement for serialisation. The JVM can create instances during serialisation directly, without calling the constructor. (Even though the javadoc for Serializable talks about need a no-arg constructor, this is only a requirement for a non-serialization superclass with a serializable sub-class).
>
>
>Stuart
>
>
>>LieGrue,
>>strub
>>
>>
>>
>>----- Original Message -----
>>
>>From: Stuart Douglas <stuart.w.douglas at gmail.com>
>>>
>>To: Mark Struberg <struberg at yahoo.de>
>>>
>>Cc: Jozef Hartinger <jharting at redhat.com>; cdi-dev <cdi-dev at lists.jboss.org>
>>>
>>Sent: Thursday, October 20, 2011 6:54 AM
>>>
>>Subject: Re: [cdi-dev] Question for clarification and my understanding
>>>
>>
>>>
>>I thought that interceptors had to be done via subclassing as well, as the spec 
>>>
>>does not specify that intercepted beans have to have a default constructor?
>>>
>>
>>>
>>Stuart
>>>
>>
>>>
>>
>>>
>>On 20/10/2011, at 3:44 PM, Mark Struberg wrote:
>>>
>>
>>>
>>The spec says that only Decorators need to be done via subclassing.
>>>>
>>
>>>>
>>LieGrue,
>>>>
>>strub
>>>>
>>
>>>>
>>
>>>>
>>
>>>>
>>----- Original Message -----
>>>>
>>From: Jozef Hartinger <jharting at redhat.com>
>>>>>
>>To: Rick Hightower <richardhightower at gmail.com>
>>>>>
>>Cc: cdi-dev <cdi-dev at lists.jboss.org>
>>>>>
>>Sent: Wednesday, October 19, 2011 7:33 PM
>>>>>
>>Subject: Re: [cdi-dev] Question for clarification and my understanding
>>>>>
>>
>>>>>
>>Only normal scoped beans require client proxies. Decoration and 
>>>>>
>>interception should be implemented by subclassing (see CDI-74, CDI-44).
>>>>>
>>
>>>>>
>>On 10/19/2011 07:24 PM, Rick Hightower wrote:
>>>>>
>>
>>>>>>
>>Section 5.4
>>>>>>
>>
>>>>>>
>>"Client proxies are never required for a bean whose scope is a 
>>>>>>
>>
>>>
>>pseudo-scope such as @Dependent."
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>I understand the concept of client proxies to allow for scopes and 
>>>>>>
>>context.
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>Is this a true statement...
>>>>>>
>>
>>>>>>
>>Client proxies may not be needed for @Dependent (pseudo scope). CDI 
>>>>>>
>>
>>>
>>may provide a client proxy for @Dependent.
>>>>>>
>>A proxy is needed for @Dependent objects that are decorated or 
>>>>>>
>>intercepted with Decorators or Interceptors.
>>>>>>
>>
>>>>>>
>>Are all injected objects proxied or only objects that are normal 
>>>>>>
>>scoped or decorated?
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>-- 
>>>>>>
>>*Rick Hightower*
>>>>>>
>>(415) 968-9037
>>>>>>
>>Profile <http://www.google.com/profiles/RichardHightower>
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>
>>>>>>
>>_______________________________________________
>>>>>>
>>cdi-dev mailing list
>>>>>>
>>cdi-dev at lists.jboss.org
>>>>>>
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>_______________________________________________
>>>>>
>>cdi-dev mailing list
>>>>>
>>cdi-dev at lists.jboss.org
>>>>>
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>
>>>>>
>>_______________________________________________
>>>>
>>cdi-dev mailing list
>>>>
>>cdi-dev at lists.jboss.org
>>>>
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>
>>>
>
>
>