[cdi-dev] Can proxying be handled the way done in EJB?

[Martin Kouba]

Hi John,

comments inline..

Dne 10.2.2016 v 14:12 John D. Ament napsal(a):
> Not sure if we want to pollute the vote thread, so changing titles.

Makes sense.

>
> I think to summarize my feelings, think about the relationship between
> interface Foo and implementation FooImpl.  Foo is defined:
>
> interface Foo {
>     String doWork();
> }
>
> FooImpl is defined as:
>
> public class FooImpl implements Foo {
>     public String doWork() { return "i'm done"; }
>
>     public final String doSomethingElse() { return "something else"; }
>
> }
>
> The way CDI impls work right now, the proxy is created for the impl.
> The way EJBs proxy right now, they proxy the interface.  If CDI proxied
> both the interface and impl separately, and substituted based on the
> injection point, this would work.

If you create two proxies, one for Foo and one for FooImpl, then it 
would only work for @Inject Foo -  if we @Inject FooImpl then we have 
the same problem (at least with subclassing).

>
>
> On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     Dne 10.2.2016 v 13:48 John D. Ament napsal(a):
>      > +1 for adding this feature to the spec.
>      >
>      > -1 for adding it the way it is written currently.  This isn't to say
>      > that Mark's idea is bad, its just that it puts too much onus on the
>      > application developer to know the structure of its classes, both
>      > internally developed and externally provided.
>      >
>      > We should follow a pattern closer to EJB (in my opinion) where the
>      > non-proxyable methods are just not proxied - you won't get
>     transactions,
>      > etc available.
>
>     -1
>
>     I think you cannot declare a final method on a NIV session bean (you get
>     validation error) and it's easy to create a proxy for local/remote
>     interface - no such methods. I also think we cannot implement this in
>     Weld as we're using subclassing for client proxies. If you don't
>     override (i.e. if you ignore) such a method than it will not be invoked
>     upon the contextual instance but upon the clien proxy instance
>     (subclass).
>
>      >
>      > John
>      >
>      > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand
>      > <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>
>     <mailto:antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>>
>     wrote:
>      >
>      >     Hi all,
>      >
>      >     There have been a lot of discussion around CDI-527 in the
>     last weeks:
>      > https://issues.jboss.org/browse/CDI-527
>      >
>      >     Mark proposed a PR:
>      > https://github.com/cdi-spec/cdi/pull/271
>      >
>      >     But we don't agree on adding this feature to the spec.
>      >     This vote is to decide if we should add this feature at the spec
>      >     level now, or not.
>      >     Should we vote this feature down, that won't mean it will be
>      >     completely dropped: it could be implemented as non portable
>     feature
>      >     in both Spec or even be included as experimental feature in
>     the spec
>      >     (in annexes) as describe in the PR comments
>      >     Vote starts now, only vote from EG members are binding (but
>     you can
>      >     give your opinion if not part of the EG) and will last 72 hours.
>      >
>      >     You vote with the following values:
>      >     +1 : I'm favorable for adding this feature in the spec
>      >     -1 : I'm against adding this feature in the spec
>      >     0 : I don't care
>      >
>      >     Thank you for your attention and your vote.
>      >
>      >     Antoine Sabot-Durand
>      >     _______________________________________________
>      >     cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>     <mailto:cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/cdi-dev
>      >
>      >     Note that for all code provided on this list, the provider
>     licenses
>      >     the code under the Apache License, Version 2
>      >     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>      >     ideas provided on this list, the provider waives all patent and
>      >     other intellectual property rights inherent in such information.
>      >
>      >
>      >
>      > _______________________________________________
>      > cdi-dev mailing list
>      > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/cdi-dev
>      >
>      > Note that for all code provided on this list, the provider
>     licenses the code under the Apache License, Version 2
>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>     ideas provided on this list, the provider waives all patent and
>     other intellectual property rights inherent in such information.
>      >
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic