7:36 a.m.
Indeed, or as simple as having the producer not create a SomeBlaImpl but the SomeBla
interface.
That was my case a) in the CDI ticket. And of course this should be prefered to the
allowProxing exception. BUT you 1.) not always have an interface and 2.) sometimes (like
with some JDK classes) you really need the impl and 3.) sometimes you need to create
subclasses of a 3rd party class. And with subclassing there is no way to get rid of a
final method :/
LieGrue,
strub
Am 10.02.2016 um 14:12 schrieb John D. Ament
<john.d.ament(a)gmail.com>:
Not sure if we want to pollute the vote thread, so changing titles.
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.
On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba <mkouba(a)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(a)sabot-durand.net <mailto:antoine@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(a)lists.jboss.org <mailto:cdi-dev@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(a)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
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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.