Read what I could get my hands on. Unfortunately the JIRA itself has 36 comments which won’t load/expand in Safari or Chrome. But I think I get the summary.
High level, I agree with both Mark and Martin.
- Agree with Mark: Where I see this feature being important is in our EJB/CDI alignment efforts. This appears to be the rare case where the CDI spec is more strict than the EJB spec and a speed bump in someone’s efforts to port an EJB application to CDI. For that reason, this to me upgrades from nice-to-have to we-must-find-a-way.
- Agree with Martin: I also strongly dislike the use of beans.xml in any fashion and system properties even more. Aside from being cumbersome for users, I’m particularly against setting a trend of using system properties to bail us out of hard API design issues. This concern trumps the above and I would -1 this vote as-is.
That said, I’m not sure if this approach is workable in any way, but here goes:
We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is:
- explicitly produced via @Produces
- added explicitly via an extension
Effectively the BeanManager would continue to ignore beans with final methods as proxyable in a classpath scan, but the application could “go back” and explicitly put them into the BeanManager as proxyable.
Thoughts? Big holes in there?
-David
Hi Guys,
Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here.
I find interesting to have the more possible input but as the rules were to end the vote tonight, I wanted to be sure that nobody has any objection for closing the vote on sunday 11:59pm CET.
Regards,
Antoine
Sure, that might probably be a viable way to do it.
Oki, here are the two use cases which we need to solve:
1.)
@Produces
@ApplicationScoped
public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …};
2.)
@ApplicationSCoped
public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {}
Any other use case?
Can you please elaborate how your idea will look like? Just a few ideas so we can get it running.
txs and LieGrue,
strub
PS: Again: I’m NOT interested to get my approach in. All I’m interested in is a _solution_ for this real world problem. But there was simply no alternative proposed so far…
> Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir@redhat.com>:
>
> -1
>
> The problem seems real, but proposed approach doesn't sit right with
> me. I think it would be better to follow the EJB approach, and add a
> way to be able to declare a method as "not a business method" (a
> business method is also a thing in CDI IIRC).
>
> For example, e.g. using beans.xml and an annotation. This then allows
> the spec to consistently treat this public method as not a business
> method.
>
> On 9 February 2016 at 16:36, Antoine Sabot-Durand
> <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@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@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@lists.jboss.orghttps://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.