Thoughts about CDI-527
by Antoine Sabot-Durand
Hi guys,
Re-reading materials and all our discussion on CDI-527, I think there's an
option we didn't explore
Instead of introducing a new annotation, we could loose rules on proxied
bean creation for class having final methods.
Today if you declare a class requiring a proxy (because of scope or AOP)
you'll get an exception, so nobody declares a bean with such a feature
since the app wouldn't deploy.
It's the same for producer: you won't declare an @ApplicationScoped
producer for a type having final method since your app won't deploy.
So in today existing code, final method are in non cdi code or in cdi code
that doesn't requires proxy (@Dependent without AOP)
If we decide to loose the rules in "3.15 Unproxyable bean types" [1] it
won't have impact on existing code (unless I missed something), since you
can't have proxied bean with final method without deployment error.
It would only allow new proxied bean with final method in it.
Change should also be made in "7.2. Container invocations and interception"
[2] to explicitly exclude final methods from the list of business method.
This change could be seen as not backward compatible, but since current
code cannot have proxied bean with final class it doesn't change existing
behavior but allow new usage.
It also allow code with producer for class of the JDK introducing final in
their code to continue working seamlessly in CDI 2.0.
Finally that prevent us to introduce specific annotation or configuration
looking like a hack.
In the past we already introduce behavior changes when we changed the list
of bean defining annotation in CDI 1.2 or when we loose usage of certain
beanManager method in AfterBeanDiscovery event (I see this proposal very
like this last example).
Wdyt ?
Antoine
[1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#unproxyable
[2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method
9 years
preparation for todays meeting
by Mark Struberg
Hi folks!
I would love to discuss CDI-420 today.
This is open since 2 years now and I’ve shipped a pull request already 2 weeks ago.
LieGrue,
strub
9 years
Full rewrite for CDI 558 / PR 270
by Antoine Sabot-Durand
Hi all,
Following discussion during last meeting, I rewrote most of my PR for
builders.
We now have 2 clean and distinct ways of using them
1) in DSL style (with a Configurator interface without build() method)
public void processAT(@Observes ProcessAnnotatedType<?> pat) {
pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new
AnnotationLiteral<MyInterceptor>() {};);
}
2) In classical reusable builder mode (builders extends configurator and
only add build() method)
public void processAT(@Observes ProcessAnnotatedType<?> pat) {
AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder();
atb.read(pat.getAnnotatedType()).addToType(new
AnnotationLiteral<MyInterceptor>() {};);
pat.setAnnotatedType(atb.build());
}
As Configurators don't have build() method there's no risk that users mix
them with standard builders.
For clarity sake, builders are no more available in lifecycle event but in
Builders class for consistency.
I'm quite happy with the result, but I'm sure you'll have comment ;). So
thanks for your feedback
https://github.com/cdi-spec/cdi/pull/270
Antoine
9 years
adding generic producers to CDI 2.0?
by Romain Manni-Bucau
Hi guys,
could CDI 2 do step forward for generic producers?
The need is to produce any type (with a particular qualifier) without the
need of an extension:
@Produces
@MyQualifier
Object create(InjectionPoint ip) { ... }
This is actually a common pattern (for configuration, or to integrate with
3rd party libs) and today the only hope to do so is to write an extension
which is a bit technical and verbose for the result IMO.
I guess for compatibility reason we would need to do something like:
@Produces
@MyQualifier
@Generic
Object create(InjectionPoint ip) { ... }
and say that if there is a unique resolved bean thanks to qualifiers which
is annotated @Generic then use this producer.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
9 years
Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods
by Florent Benoit
+1 : I'm favorable for adding this feature in the spec
On Tue, Feb 9, 2016 at 5:36 PM, Antoine Sabot-Durand <
antoine(a)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
> 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.
>
9 years
