Interceptors and JDK 8 default methods
by arjan tijms
Hi,
I've got a CDI bean implementing an interface with several default methods.
The bean implements one of those methods.
When I place an interceptor on said bean, and call the different methods
via the CDI proxy, only the method that the bean implemented is
intercepted. The defaulted methods go straight to the implementation
provided by the interface.
Tested with Weld 2.3.2 on WildFly 10cr5.
Is this supposed to work?
Kind regards,
Arjan Tijms
8 years, 11 months
CDI + 3rd party DI frameworks
by Paul Benedict
Hello EG members. I have a question regarding this statement from the
"Parts CDI Workshop doc". The line is: "Allow 3rd parties to implement
easily this subpart of CDI"
One thing, which has constantly frustrated me when using CDI 1.x, is the
lack of seamless integration with popular/proprietary DI frameworks (like
Spring). Regarding my experience with CDI+Spring in one app, I annotate CDI
injection points one way, and Spring injection points another way. I do not
like this schism and always seek to resolve it the best I can, but it's
never satisfactory to me.
It's my hope that, one day, custom DI frameworks that boot-up inside an app
can join themselves to the CDI engine and be able offer up their beans
through a CDI SPI. When the app tears down, so does the 3rd party framework
and those beans are no longer available. Thus, I would like CDI to offer
integration service points so that bean contexts/archive are, in a sense,
federated.
Is anything like this planned for 2.0? Or, if this idea is brand new, what
do you think of it?
Cheers,
Paul
8 years, 12 months
Review needed for PR 270 (CDI 558)
by Antoine Sabot-Durand
Hi guys,
I just finish the first api version for CDI-558 (
https://issues.jboss.org/browse/CDI-558).
The spec part is not yet here, since I wanted to discuss the API with you
before.
We probably should discuss the following point:
- Package and class name
- Access to AnnotatedTypeBuilder (the only builder accessible while no CDI
container is running)
- Specification of exception in unauthorized called in these builder.
Your feedback is most welcome.
Antoine
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
Martin, to come back to your argument that it won't help for legacy apps. It would not help if you have a sealed WAR/EAR anymore which you cannot change. But you can add a simple small jar to them which contains just the beans.xml with those additional settings almost always. You can even put this into the shared classpath without changing your EAR/WAR...
So I think it is the closest we can get. Again: happy for any other good solution. But doing nothing is not an option in my opinion.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
This has exactly NOTHING to do with merging info from beans.xml. Nor has @Alternative any problems with merging beans.xml btw. The ONLY case where this might make problems is for decorators and interceptors!
Any other arguments? Because this is not a valid argument so far.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-527:
----------------------------------
bq. as I already said many weeks ago...
Sometimes there is no good solution. Also for legacy applications this beans.xml approach wouldn't help either - if it is possible to change the app, then in most cases the "interface workaround" mentioned in A. might be used.
bq. And no, as discussed and agreed many times...
Not agreed. However, this issue is not a good place to discuss the problem. One of the things which is not "perfectly covered" is merging of {{beans.xml}} within an existing EE module.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-577) Non-Dependent scope specified on Decorator
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-577?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-577:
-----------------------------------
+1 for detecting this user error at startup .
> Non-Dependent scope specified on Decorator
> ------------------------------------------
>
> Key: CDI-577
> URL: https://issues.jboss.org/browse/CDI-577
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators
> Affects Versions: 1.0, 1.2.Final
> Reporter: Emily Jiang
> Priority: Minor
>
> In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors.
> At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.
> Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:
> If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-577) Non-Dependent scope specified on Decorator
by Emily Jiang (JIRA)
Emily Jiang created CDI-577:
-------------------------------
Summary: Non-Dependent scope specified on Decorator
Key: CDI-577
URL: https://issues.jboss.org/browse/CDI-577
Project: CDI Specification Issues
Issue Type: Clarification
Components: Decorators
Affects Versions: 1.2.Final, 1.0
Reporter: Emily Jiang
Priority: Minor
In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors.
At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.
Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:
If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
as I already said many weeks ago: give us a better solution and we will think about it. But blocking all solutions for a REAL issue is contraproductive...
And no, as discussed and agreed many times (also by JBoss), both interpretations of the term BDA are perfectly covered by the spec.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
